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GLOSSARY 


Analysis:  “Separation  of  a  whole  into  its  component  parts”  [Mish,  1994:  41]. 

Context:  “A  set  of  entities  that  can  impact  the  system  but  cannot  be  impacted  by  the 
system”  [Buede,  2000:  38]. 

Commander’s  Intent:  “A  concise  expression  of  the  purpose  of  the  operation  and  the 
desired  end  state”  [JP  1-02,  2008]. 

Doctrine:  “Fundamental  principles  by  which  the  military  forces  or  elements  thereof 
guide  their  actions  in  support  of  national  objectives.  It  is  authoritative  but  requires 
judgment  in  application”  [JP  1-02,  2008]. 

External  Systems:  “A  set  of  entities  that  interact  with  the  system  via  the  system's 
external  interfaces”  [Buede,  2000:  38]. 

Mission:  “The  task,  together  with  the  purpose,  that  clearly  indicates  the  action  to  be 
taken  and  the  reason  therefore”  [JP  1-02,  2008]. 

Process:  “A  series  of  actions  or  operations  conducing  to  an  end”  [Mish,  1994:  929]. 

Synthesis:  “The  composition  or  combination  of  parts  or  elements  so  as  to  form  a  whole” 
[Mish,  1994:  1197]. 

System:  “A  set  of  components  (subsystems,  segments)  acting  together  to  achieve  a  set  of 
common  objectives  via  the  accomplishment  of  a  set  of  tasks”  [Buede,  2000:  38], 

Task:  An  action  or  activity  (derived  from  an  analysis  of  the  mission  and  concept  of 
operations)  assigned  to  resource  to  provide  a  capability  [after  CJCSM  3400. 04D,  2005: 
Enclosure  A,  6]. 
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EXECUTIVE  SUMMARY 


Command  and  control  (C2)  is  an  enigma  that  has  been  studied  by  military  leaders 
and  warfare  analysts  for  hundreds  of  years.  As  a  result  of  the  numerous  definitions  and 
concepts  of  C2  throughout  history,  the  design  of  a  C2  system  is  a  daunting  challenge  to 
the  systems  engineer,  whose  duties  include  eliciting  the  operational  needs  of 
stakeholders;  identifying  appropriate  system  requirements;  developing  a  systems 
architecture  from  which  specialized  engineers  can  design  and  build  the  applicable 
configurable  items;  and  integrating  such  configurable  items  to  produce  a  system  that 
meets  the  needs  of  the  stakeholders.  Adding  to  the  challenge  is  the  understanding  and 
integration  of  new  operational  concepts  identified  by  stakeholders  as  necessary  to  meet 
their  operational  needs.  Network-Centric  Warfare  (NCW)  is  one  such  operational 
concept  that  has  implications  on  the  design  and  development  of  C2  systems. 

There  has  been  much  work  conducted  to  date  to  enable  NCW  by  networking 
combat  and  information  systems  and  by  removing  the  “stove-pipes”  of  legacy  systems. 

A  military  C2  system,  however,  is  more  than  the  technology  and  equipment  that  comprise 
it.  It  also  includes  the  doctrine,  organization,  training,  leadership,  personnel,  and 
facilities  surrounding  the  material.  It  is  imperative  for  the  systems  engineer  to  understand 
the  implications  of  each  portion  of  DOTMLPF  on  the  life-cycle  of  the  system 

This  thesis  dissects  the  complex  engineering  process  of  naval  tactical  C2  systems 
in  order  to  identify  the  points  of  integration  between  doctrine  and  material.  The  goal  was 
to  better  understand  the  influence  of  doctrine  on  the  overall  architecture  of  the  material 
system  in  order  to  ensure  developing  net-centric  systems  and  net-centric  doctrine  meet 
the  command  and  control  needs  of  tactical  naval  forces. 

To  begin  such  study,  this  thesis  presented  concepts  of  command  and  control 
developed  by  military  leaders  and  enthusiasts  throughout  history.  The  works  of  Sun  Tzu 
[1971,  1994],  Clausewitz  [1984],  Van  Creveld  [1985],  and  Alberts  and  Hayes  [2006], 
along  with  military  publications  by  the  U.S.  Army  [FM  6-0,  2003],  U.S.  Air  Force 
[AFDD  1,  2003],  U.S.  Marine  Corps  [MCDP,  1996],  U.S.  Navy  [NDP  6,  1995],  and  the 
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North  Atlantic  Treaty  Organization  [NSA,  2008]  were  reviewed.  From  the  survey  and 
analysis  of  texts  and  publications,  the  author  concluded  that  C2  should  be  viewed  as  part 
of  a  function-process-system  combination. 

First,  when  a  specific  entity  is  designated  as  responsible  for  the  accomplishment 
of  a  mission,  command  is  a  function  by  which  the  responsible  entity  takes  inputs  (e.g., 
mission  objective,  assigned  forces,  operating  environment,  adversary’s  capabilities,  etc.) 
to  produce  the  desired  output  (i.e.,  accomplishment  of  the  mission  objective).  Second, 
command  and  control  is  the  process  by  which  the  inputs  generate  the  outputs.  Third,  a 
command  and  control  system  is  the  means  by  which  the  process  is  executed.  When  there 
is  no  specific  entity  designated  as  responsible  for  the  accomplishment  of  a  mission,  the 
C2  process  and  the  C2  system  can  still  take  inputs  to  produce  the  desired  output.  In  such 
a  case,  inputs  to  the  C2  system  such  as  mission  objective  may  be  generated  during  the 
command  and  control  process  or  never  generated  at  all. 


Figure  1.  Command  and  Control:  Function-Process-System 
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Following  the  survey  of  texts  and  publications,  the  thesis  progressed  through  the 
system  architectural  methodology  developed  by  Alexander  Levis  as  presented  by  Buede 
[2000]  and  Levis  and  Wagenhals  [2000],  The  methodology  begins  with  the  operational 
concept,  moves  to  the  co-development  of  functional  architecture  and  physical 
architectures,  and  concludes  with  the  development  of  operational  architecture. 


Figure  2.  Architecture  Development  [from  Buede,  2000:  20] 

The  first  phase  in  the  architectural  process  was  development  of  the  operational 
concept.  The  operational  concept  was  a  general  vision  of  the  system  from  the  view  of 
stakeholders  [Buede,  2000],  It  identified  the  boundaries  of,  inputs  to,  outputs  from, 
objectives  for,  and  requirements  of  the  system.  First,  several  employment  scenarios 
describing  the  operational  use  of  a  naval  tactical  C2  system  were  developed.  Next, 
incorporating  NCW,  a  refined  problem  statement  was  defined: 

A  responsive  and  robust  command  and  control  system  which  connects 
dispersed  forces  and  enables  such  forces  to  self-synchronize  and  allocate 
resources  to  mass  effects  in  order  to  meet  the  established  intent  at  the 
tactical  level  of  war. 

An  external  systems  diagram  was  then  developed  to  define  the  boundaries  of  the  system 
and  to  describe  the  interactions  with  the  system  for  applicable  stakeholders.  The  external 
systems  diagram  identifies  interactions  with  external  systems  and  the  system  context  (i.e., 
“A  set  of  entities  that  can  impact  the  system  but  cannot  be  impacted  by  the  system” 
[Buede,  2000:  38]). 

The  function-process-system  concept  of  C2  was  also  used  in  the  development  of 
the  external  systems  diagram,  which  is  evident  in  the  identification  of  the  commander  as 

xxiii 


an  external  system.  Since  the  command  and  control  system  is  the  means  by  which  the 
command  and  control  process  executes  the  function  of  command  for  the  commander,  the 
commander  is  not  a  component  of  the  system.  In  addition,  the  the  external  systems 
diagram  identifies  candidate  subsystems  and  configurable  items. 


CONTEXT 


Figure  3.  Basic  External  Systems  Diagram 

The  refined  problem  statement,  again  in  conjunction  with  the  function-process- 
system  concept  of  C2,  guided  the  development  of  a  system  objectives  hierarchy.  The 
purpose  of  the  systems  objectives  hierarchy  was  to  organize  the  system’s  objectives  from 
the  view  of  applicable  stakeholders.  The  development  of  the  systems  objectives 
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hierarchy  also  included  the  identification  of  Measures  of  Merit  (MoM)  by  which  different 
potential  designs  of  the  C2  system  could  be  compared.  Completion  of  the  system 
objectives  hierarchy  marked  the  conclusion  of  the  operational  concept  phase. 

A  responsive  and  robust  command  and  control  system  which 
connects  dispersed  forces  and  enables  such  forces  to  self- 
synchronize  and  allocate  resources  to  mass  effects  in  order  to  meet 
the  established  intent  at  the  tactical  level  of  war. 


Figure  4.  System  Objectives  Hierarchy 

The  second  phase  in  the  architectural  process  was  the  co-development  of 
functional  and  physical  architectures.  The  purpose  of  the  functional  architecture  was  to 
describe  what  the  system  was  to  do  with  the  identified  inputs  to  produce  the  desired 
outputs.  The  first  step,  which  was  based  on  the  review  of  texts  and  publications 
concerning  the  concept  of  C2,  was  the  development  of  a  functional  hierarchy.  Six  top- 
level  functions  which  a  C2  system  performs  were  identified:  Transport  Information, 
Process  Information,  Store  Information,  Present  Information,  Generate  Response 
Options,  and  Select  Response  Options.  These  six  functions  were  then  decomposed  into  a 
hierarchy  of  sub-functions  which  were  then  assigned  to  different  resources  identified  in 
the  physical  architecture  to  form  the  operational  architecture. 
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The  next  step  of  the  functional  architecture  was  to  detail  the  relationships  between 
the  inputs  and  outputs  of  the  system  (i.e.,  describe  the  sequence  of  functions  converting 
an  input  into  an  output).  IDEFO  was  selected  as  the  method  to  detail  these  relationships. 
The  relationships  of  the  top-level  functions  are  presented  in  Figure  5. 
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Figure  5.  Relationship  Diagram  -  A0 
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The  purpose  of  the  physical  architecture  was  to  describe  the  resources  that 
comprised  the  system,  with  resources  for  every  function  identified  in  the  functional 
architecture  [Buede,  2000:  215-216].  In  addition,  the  physical  architecture  described 
procedures  by  which  the  system  was  used  [Buede,  2000:  218]  and  controls  on  the 
system.  Generic  components,  procedures,  and  controls  are  also  presented  above  in 
Figure  5.  The  final  step  of  the  physical  architecture  was  development  of  instantiated 
physical  architectures  from  which  two  potential  alternative  designs  of  the  system  could 
be  built.  Differences  between  the  second  and  first  alternative  designs  of  the  C2  system 
was  adoption  and  implementation  of  doctrine  which  moved  from  decentralized  decision 
and  allocation  authority  to  distributed  decision  and  allocation  authority.  From  this  point 
the  final  phase  of  the  architectural  process,  development  of  the  operational  architecture, 
began. 

The  operational  architecture  provided  a  description  of  the  system  design  by 
incorporating  products  of  the  operational  concept,  functional  architecture,  and  physical 
architecture.  First,  functions  developed  in  the  functional  architecture  were  allocated  to 
physical  components  developed  in  the  physical  architecture.  Again,  this  is  presented  in 
Figure  5.  Second,  activations  and  controls  of  functions  were  described  in  a  framework  of 
the  contact  prosecution  process,  a  use  of  a  C2  system  identified  in  the  operational 
concept.  The  functional  flow  of  a  portion  of  the  contact  prosecution  process,  for  both 
alternative  designs,  was  then  modeled  and  simulated  using  Arena®,  version  10.0  to 
demonstrate  the  ability  of  the  architecture  framework  to  analyze  and  compare  system 
designs. 

The  approach  and  results  of  the  thesis  demonstrated  only  a  portion  of  the  system 
engineering  process  (i.e.,  system  architecture  phases)  focused  on  a  small  portion  of  the 
command  and  control  problem  (i.e.,  the  needs  of  a  Surface  Action  Group  tasked  to  secure 
local  sea  control  in  traditional  operating  environments),  all  at  a  highly  conceptual  level. 
This  thesis,  however,  demonstrated  the  significant  impact  of  doctrine  on  each  phase  of 
the  system  architectural  process  and,  subsequently,  on  the  design  of  C2  systems.  NCW  is 
more  than  a  framework  to  view  missions,  strategies,  tactics,  techniques,  procedures,  and 
organizations  available  to  a  networked  force;  it  effects  more  than  the  deployment  of  a  C2 
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system.  This  thesis  showed  how  NCW  affects  the  definition,  objectives,  measures,  and 
functions  of  the  C2  system;  design  of  candidate  C2  physical  architectures;  allocation  of 
functions  to  selected  physical  components;  and  flow  of  the  C2  process.  This  thesis,  its 
approach,  and  its  conclusions  provide  future  researchers  with  numerous  areas  of  potential 
study  and  can  assist  in  the  development  and  integration  of  net-centric  systems  and  net- 
centric  doctrine  to  meet  the  command  and  control  needs  of  future  tactical  naval  forces. 
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I.  INTRODUCTION 


A.  BACKGROUND 

The  role  of  the  systems  engineer  is  to  elicit  the  operational  needs  of  the  customer; 
identify  appropriate  system  requirements;  develop  a  system  architecture  from  which 
specialized  engineers  can  design  and  build  the  applicable  configurable  items;  and 
integrate  such  configurable  items  to  produce  a  system  which  meets  the  needs  of  the 
customer.  Systems  engineers  must  be  cognizant  of  every  phase  in  the  system’s  life-cycle. 
This  includes  the  development,  manufacturing,  operations,  and  retirement  phases. 

Network-Centric  Warfare  (NCW)  is  an  operational  concept  the  U.S.  military  has 
identified  to  meet  its  operational  needs.  NCW  has  implications  on  the  development  of 
many  systems  the  systems  engineer  supports,  including  command  and  control  systems. 
There  has  been  much  work  conducted  to  date  to  enable  NCW  by  networking  combat  and 
information  systems  and  by  removing  the  “stove-pipes”  of  legacy  systems.  A  military 
system,  however,  is  more  than  the  technology  and  equipment  which  comprise  it.  It  also 
includes  the  doctrine,  organization,  training,  leadership,  personnel,  and  facilities 
surrounding  the  material.  It  is  imperative  for  the  systems  engineer  to  understand  the 
implications  of  each  portion  of  DOTMLPF  on  the  life-cycle  of  the  system. 

B.  PURPOSE 

Command  and  control  is  an  enigma  which  has  been  studied  by  military  leaders 
and  warfare  analysts  for  hundreds  of  years.  Joining  this  study  enables  the  system 
engineer  to  design  and  develop  more  effective  command  and  control  systems.  To  this 
study  systems  engineers  bring  particular  professional  expertise,  namely  the  practice  of 
dividing  complex  problems  into  as  many  parts  is  as  necessary  to  determine  the  solution 
and  gaining  greater  understanding  of  the  solution  through  the  study  and  assembly  of  the 
simpler  portions  of  the  problem  [Descartes,  1850:  61]. 

This  thesis  dissects  the  complex  engineering  process  of  naval  tactical  command 

and  control  systems  in  order  to  identify  the  points  of  integration  between  doctrine  and 

material.  The  goal  was  to  better  understand  the  influence  of  doctrine  on  the  overall 
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architecture  of  the  material  system  in  order  to  ensure  developing  net-centric  systems  and 
net-centric  doctrine  meet  the  command  and  control  needs  of  tactical  naval  forces. 

C.  RESEARCH  QUESTIONS 

Questions  specifically  addressed  in  the  research  for  this  thesis  include: 

•  What  are  the  Measures  of  Effectiveness  (MOE)  for  naval  tactical  command  and 
control? 

•  How  does  doctrine  impact  the  Measures  of  Effectiveness? 

•  How,  and  where,  does  doctrine  impact  the  system  engineering  process  for  a  naval 
tactical  command  and  control  system? 

D.  BENEFITS  OF  STUDY 

The  benefits  of  this  thesis  are: 

•  to  facilitate  communication  between  the  warfighter  and  system  engineer  to  enable 
the  integration  of  the  net-centric  doctrine  written  by  the  warfighter  and  the  net-centric 
systems  developed  by  the  system  engineer  for  the  warfighter; 

•  to  provide  an  example  for  further  research  of  the  implications  of  organization, 
training,  leadership,  personnel,  and  facilities  on  the  system  engineering  process; 

•  to  provide  frameworks  enabling  modeling,  simulation,  and  analysis  of  command 
and  control  systems  for  naval  tactical  units. 

E.  SCOPE  AND  METHODOLOGY 

The  focus  of  this  thesis  was  on  the  interaction  of  doctrine  and  material  (of 
DOTMLPF)  and  their  subsequent  implications  during  the  architectural  phases  of  the 
system  engineering  process.  The  three  primary,  conceptual  systems  engineering  life- 
cycle  phases  are  system  definition,  system  development,  and  system  deployment  [Sage  & 
Armstrong,  2000:  49].  The  architectural  phases  of  the  system  engineering  process 
encompass  the  system  definition  and  the  initial  portion  of  system  development. 
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Specifically,  this  thesis  focused  on  the  mission  needs  of  tactical  naval  units  (i.e.,  Surface 
Action  Group)  in  traditional  operating  environments  in  10  to  15  years. 


Figure  6.  Conceptual  Systems  Engineering  Life-Cycle  Phases  [from  Sage  &  Armstrong, 

2000:  49] 

The  methodology  of  architectural  phases  for  this  thesis  followed  the  system 
engineering  process  developed  by  Alexander  Levis  and  presented  by  Buede  [2000]  and 
Levis  and  Wagenhals  [2000].  The  process  starts  with  the  operational  concept,  moves  to 
the  co-development  of  the  functional  architecture  and  the  physical  architecture,  and 
concludes  with  the  development  of  the  operational  architecture.  The  functional 
architecture  defines  what  it  is  the  system  is  required  to  do.  The  physical  architecture 
describes  the  physical  resources  and  procedures  for  performing  the  system's  functions. 
The  operational  architecture  integrates  the  functional  and  physical  architectures  through 
the  mapping  of  the  functions  to  resources. 


Figure  7.  Architecture  Development  [from  Buede,  2000:  20] 
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II.  OVERVIEW  OF  COMMAND  AND  CONTROL 


A.  INTRODUCTION 

Command  and  control  is  an  enigma  which  has  been  studied  by  military  leaders 
and  warfare  analysts  for  hundreds  of  years.  The  oldest  commonly  known  writings 
concerning  command  and  control,  Sun  Tzu’s  discussions  on  the  balancing  of  the  five 
fundamental  factors  of  war,  were  arguably  written  nearly  2300  years  ago  [Sun  Tzu,  1971 : 
11].  Despite  the  long  history  of  the  subject,  significant  research  concerning  the  principles 
of  command  and  control  only  began  within  the  past  half-century  [Lawson,  1981;  Levis  & 
Athans,  1992;  Van  Creveld,  1985].  With  each  emerging  theory  of  warfare  and  every  new 
communications  technology,  the  problems  concerning  the  design  and  evaluation  of 
command  and  control  systems  become  more  daunting  and  complex. 

The  systems  engineer  tasked  with  developing  a  command  and  control  system  can 
benefit  greatly  from  joining  the  study  and  analysis  of  what  exactly  is  command  and 
control.  A  crucial  task  for  the  system  engineer  is  to  continuously  communicate  with 
system  stakeholders  concerning  their  expectations  for  the  system.  Though  such 
communication  may  be  difficult  it  is  necessary  for  the  design  of  a  system  which  can  be 
used  effectively.  Researching  historical  and  current  works  concerning  command  and 
control  becomes  one  means  of  interacting  with  stakeholders.  Additionally,  such  research 
can  provide  the  systems  engineer  with  a  better  understanding  of  stakeholders’  points  of 
view  and  a  common  vocabulary  for  communication.  This  chapter  provides  a  basic 
overview  of  stakeholders’  past,  present  and  future  concepts  of  command  and  control. 

B.  CONCEPT  OF  COMMAND  AND  CONTROL 

Some  experts  propose  that  a  person  seeking  substantially  innovative  concepts  in 
command  and  control  is  “arguably  better  off  approaching  the  subject  untainted  by 
traditional  Command  and  Control  concepts”  [Alberts  &  Hayes,  2006:  31].  Such 
ignorance  can  be  beneficial,  but  it  can,  unfortunately,  be  a  detriment  to  the  systems 
engineer.  Without  an  understanding  of  the  vocabulary  and  points  of  view  of  the  systems’ 
stakeholders,  a  systems  engineer  will  struggle  to  have  the  necessary,  effective 
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communication  with  the  stakeholders.  A  stakeholder’s  point  of  view  of  command  and 
control  is  shaped  by,  among  other  things,  their  educational  background  on  the  topic  as 
well  as  their  role  in  interacting  with  the  system.  To  highlight  the  similarities  and  possible 
differences  in  the  points  of  view,  the  following  sections  present  textual  and  doctrinal 
concepts  of  command  and  control. 

1.  Textual  Concepts  of  Command  and  Control 

Many  historical  texts  discussing  war  primarily  discussed  principles  of  war  as 
theories  and  methodologies  of  conducting  warfare.  The  texts  contained  limited  content 
specifically  correlated  to  modern  concepts  of  command  and  control.  Significant, 
published  research  specifically  concerning  the  principles  of  command  and  control  only 
began  appearing  within  the  past  half-century.  This  does  not  mean  that  a  review  of 
historical  texts  cannot  provide  the  systems  engineer  with  an  understanding  of 
stakeholders’  points  of  view  concerning  command  and  control  systems.  Actually,  a 
review  of  textual  concepts  of  command  and  control  may  allude  to  certain  stakeholders’ 
biases  and  their  potential  flexibility  in  system  definition.  The  period  of  textual  writings 
will  range  from  2300  years  ago  to  near  present  day. 

The  works  attributed  to  Sun  Tzu,  collected  and  combined  to  form  the  Art  of  War 
[Sun  Tzu,  1971;  Sun  Tzu,  1994],  are  a  military  treatise  on  military  strategy  and  war.  In 
the  presentation  of  a  theory  of  war  and  a  description  of  methodologies  of  warfare,  Sun 
Tzu  discusses  five  factors  of  warfare.  Though  translations  differ  in  their  analysis  of  the 
work,  the  five  factors  roughly  correlate  to  1)  moral  influence  of  the  ruler,  2) 
environmental  forces,  3)  physical  attributes  of  the  operating  environment,  4)  military 
leadership,  and  5)  organization  and  regulation  of  the  military.  Sun  Tzu  asserts  that  a 
general  must  understand  these  five  factors  to  be  successful  in  war  [1994:  167].  Sun  Tzu 
also  states  “Know  the  enemy,  know  yourself;  your  victory  will  never  be  endangered. 
Know  the  ground,  know  the  weather;  your  victory  will  then  be  total”  [1971 :  129].  The 
author  concludes,  therefore,  that  successful  command  requires  an  understanding  of  how 
the  uncontrollable  factors  (i.e.,  moral  influence  of  the  leader,  environmental  forces, 
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and  physical  attributes  of  the  operating  environment)  and  controllable  factors  (i.e., 
military  leadership  and  the  organization  and  regulation  of  the  military)  affect  both  the 
enemy  and  oneself. 

Clausewitz,  writing  arguably  more  than  two  thousand  years  after  Sun  Tzu  and 
being  highly  influenced  by  Romanticism  [Lynn,  2004:  Chapter  6],  attributed  successful 
command  to  his  concept  of  military  genius.  It  must  be  acknowledged,  before  any  specific 
portion  of  the  work  is  considered,  that  Clausewitz’s  On  War  is  a  posthumous  publication 
of  an  unfinished  manuscript  written  in  his  search  for  a  complete  theory  of  war.  Despite 
the  unfinished  nature  of  On  War,  the  concept  of  military  genius  discussed  in  Chapter 
Three  of  Book  One  is  reinforced  by  ideas  presented  in  Chapter  One  of  Book  One,  the 
only  portion  of  the  book  known  to  be  considered  finished  by  Clausewitz  himself 
[Clausewitz,  1984:  70].  In  Chapter  One  he  states,  among  other  things,  that  a  theory  of 
war  “must  also  take  the  human  factor  into  account,  and  find  room  for  courage,  boldness, 
even  foolhardiness.  Consequently,  it  cannot  attain  the  absolute,  or  certainty;  it  must 
always  leave  a  margin  for  uncertainty”  [p.  86].  Clausewitz’s  military  genius  is  a 
“harmonious  combination”  [p.  100]  of  elements  within  a  commander  which,  though  not 
necessarily  equally  distributed,  do  not  conflict  with  each  other.  The  elements  of  military 
genius  Clausewitz  presents  include  courage,  strength  of  body  and  soul,  intelligence,  coup 
d’oeil,  detennination,  energy  of  action,  staunchness,  endurance,  strength  of  character,  and 
imagination  (in  particular  mental  visualization)  [pp.  100-1 12]. 

Approximately  a  century  and  a  half  after  Clausewitz’s  On  War,  Martin  Van 
Creveld  published  Command  in  War.  Van  Creveld’s  work,  just  as  Sun  Tzu’s  and 
Clausewitz’s,  has  impacted  contemporary  thought  on  command  and  control  and  is 
referenced  in  numerous  publications  on  the  topic,  to  include  works  on  the  design  and 
evaluation  of  command  and  control  systems.  Command  in  War,  however,  differs  from 
On  War  and  Art  of  War,  in  that  it  focuses  primarily  on  command,  control,  and 
communications  in  war.  Van  Creveld  uses  the  term  command  to  include  the  control  and 
communications.  In  his  introduction  on  the  nature  of  command  Van  Creveld  states: 
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First  command  must  arrange  and  coordinate  everything  an  anny  needs  to 
exist  -  its  food  supply,  its  system  of  military  justice,  and  so  on.  Second, 
command  enables  the  anny  to  carry  out  is  proper  mission,  which  is  to 
inflict  the  maximum  amount  of  death  and  destruction  on  the  enemy  within 
the  shortest  possible  period  of  time  and  at  a  minimum  loss  to  itself,  [p.  6] 

Van  Creveld’s  idea  of  command  is  not  limited  to  its  associated  responsibilities. 
Command,  he  discusses,  can  also  be  viewed  by  what  it  does  [pp.  6-7].  The  processes 
within  command  include  the  collection,  storing,  retrieval,  filtering,  classifying, 
distributing,  and  displaying  of  information  concerning  one’s  forces,  the  enemy,  and  the 
environment.  The  process  of  command  also  includes  the  formation  of  an  estimate  of  the 
situation,  the  establishment  of  objectives,  the  making  of  a  decision,  detailed  planning,  the 
drafting  of  orders,  the  transmission  of  orders,  the  execution  of  the  orders,  and  the 
monitoring  of  the  execution  with  feedback.  Additionally,  Van  Creveld  argues  that  what 
command  does  remains  constant  but,  the  means  by  which  command  is  executed  changes 
with  time  [p.  9]. 


Command  and  Control  Functions 

Collecting 

Information 

Storing 

Information 

Retrieving 

Information 

Filtering 

Information 

Classifying 

Information 

Distributing 

Information 

Displaying 

Information 

Form  Estimate 
of  Situation 

Establish 

Objectives 

Make  Decision 

Plan 

Draft  Orders 

Transmit 

Orders 

Execute 

Orders 

Monitor  Order 
Execution  with 
Feedback 

Table  1.  Command  and  Control  Functions  by  Van  Creveld  [1985] 


One  of  the  most  recent  texts  concerning  command  and  control  is  Understanding 
Command  and  Control  by  Alberts  and  Hayes  [2006].  In  their  work,  Alberts  and  Hayes 
present  a  conceptual  model  of  command  and  control  built,  not  on  historical  writings  of 
the  topic  but,  on  the  view  of  a  system  tasked  with  command  and  control.  From  this 
method  of  study  Alberts  and  Hayes  conclude  that  command  and  control  is  a  “means 
toward  creating  value  (e.g.,  the  accomplishment  of  a  mission)”  [p.  32].  Additionally, 
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they  conclude  that  there  are  seven  functions  of  command  and  control:  establishing  intent; 
determining  roles,  responsibilities,  and  relationships;  establishing  rules  and  constraint; 
monitoring  and  assessing  the  situation  and  progress;  inspiring,  motivating,  and 
engendering  trust;  training  and  education;  and  provisioning  [Chapter  IV]. 


Command  and  Control  Functions 

Establish  Intent 

Define  roles, 
responsibilities  and 
relationships 

Establish  rules  and 
constraints 

Monitor  and  assess 
the  situation  and 
progress 

Inspiring, 
motivating,  and 
engendering  trust 

Training  and 
education 

Provisioning 

Table  2.  Command  and  Control  Functions  by  Alberts  and  Hayes  [2006] 


A  review  of  historical  and  contemporary  texts  on  command  and  control  in  war 
enables  the  systems  engineer  to  understand  stakeholders’  points  of  view  but,  it  is  not 
sufficient.  Review  of  stakeholders’  published  doctrine  can  also  improve  the  systems 
engineer’s  understanding  of  their  points  of  view  and  enables  establishment  of  a  common 
vocabulary  for  communication. 

2.  Doctrinal  Concepts  of  Command  and  Control 

The  U.S.  Department  of  Defense  (DoD)  and  foreign  militaries  are  key 
stakeholders  in  the  life-cycle  of  military  command  and  control  systems.  Each 
organization’s  point  of  view  of  command  and  control  is  shaped  not  only  by  their 
leadership’s  education  in  historical  works  but  also  by  their  operating  environments,  core 
capabilities,  and  force  composition.  This  section  provides  an  overview  of  command  and 
control  descriptions  and  definitions  to  assist  the  systems  engineer  with  understanding 
potential  factors  influencing  stakeholders’  views  of  the  system. 

The  DoD  definition  of  command  and  control  is: 

The  exercise  of  authority  and  direction  by  a  properly  designated 
commander  over  assigned  and  attached  forces  in  the  accomplishment  of 
the  mission.  Command  and  control  functions  are  performed  through  an 
arrangement  of  personnel,  equipment,  communications,  facilities,  and 
procedures  employed  by  a  commander  in  planning,  directing, 
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coordinating,  and  controlling  forces  and  operations  in  the  accomplishment 
of  the  mission.  [JP  1-02,2001:  102] 

Additionally,  the  DoD  defines  a  command  and  control  system  as  the  “facilities, 
equipment,  communications,  procedures,  and  personnel  essential  to  a  commander  for 
planning,  directing,  and  controlling  operations  of  assigned  and  attached  forces  pursuant 
to  the  missions  assigned”  [JP  1-02,  2001:  102], 

Each  military  branch  of  the  DoD,  despite  agreeing  to  the  joint  definition  above, 
establishes  separate  definitions  for  command  and  control  and  command  and  control 
system  in  their  service  specific  publications.  First,  the  U.S.  Army  states  “ Command  and 
control  is  the  exercise  of  authority  and  direction  by  a  properly  designated  commander 
over  assigned  and  attached  forces  in  the  accomplishment  of  a  mission.  Commanders 
perform  command  and  control  functions  through  a  command  and  control  system”  [FM  6- 
0,  2003:  1-1].  Additionally,  the  Army  defines  command  and  control  system  as  “the 
arrangement  of  personnel,  information  management,  procedures,  and  equipment  and 
facilities  essential  for  the  commander  to  conduct  operations”  [FM  6-0,  2003:  Glossary- 

4]- 

The  U.S.  Air  Force  states: 

C2  is  the  exercise  of  authority  and  direction  by  a  properly  designated 
commander  over  assigned  and  attached  forces  in  the  accomplishment  of 
the  mission.  C2  includes  both  the  process  by  which  the  commander 
decides  what  action  is  to  be  taken  and  the  systems  that  facilitate  planning, 
execution,  and  monitoring  of  those  actions.  [AFDD  1,  2003:  49-50] 

The  U.S.  Marine  Corps  defines  command  and  control  as  “the  means  by  which  a 
commander  recognizes  what  needs  to  be  done  and  sees  to  it  that  appropriate  actions  are 
taken”  [MCDP  6,  1996,  37].  Additionally,  the  U.S.  Marine  Corps  explains  “...  command 
and  control  encompasses  all  military  functions  and  operations,  giving  them  meaning  and 
harmonizing  them  into  a  meaningful  whole”  [MCDP  6,  1996:  36].  The  U.S.  Marine 
Corps  also  states  the  “basic  elements  of  our  command  and  control  system  are  people, 
information,  and  the  command  and  control  support  structure”  [MCDP  6,  1996:  52]. 
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Finally,  the  U.S.  Navy  explains: 

Command  and  control,  therefore,  refers  both  to  the  process  and  to  the 
system  by  which  the  commander  decides  what  must  be  done  and  sees  that 
his  decisions  are  carried  out.  As  defined,  the  process  of  command  and 
control  includes  the  planning,  directing,  coordinating,  and  controlling  of 
forces  and  operations,  whereas  the  system  of  command  and  control 
includes  the  personnel,  equipment,  communications,  facilities,  and 
procedures  employed  by  a  commander.  [NDP  6,  1995:  6] 

In  contrast  to  the  U.S.  military  services,  the  North  Atlantic  Treaty  Organization 
(NATO)  does  not  specifically  define  the  term  command  and  control.  The  terms 
command,  control,  and  command  and  control  system,  however,  are  defined  by  the  NATO 
Standardization  Agency  (NSA).  First,  NSA  defines  command  as  “The  authority  vested  in 
an  individual  of  the  armed  forces  for  the  direction,  coordination,  and  control  of  military 
forces”  [NATO  Standardization  Agency,  2008:  2-C-9].  Second,  NSA  defines  control  as 
“That  authority  exercised  by  a  commander  over  part  of  the  activities  of  subordinate 
organizations,  or  other  organizations  not  normally  under  his  command,  which 
encompasses  the  responsibility  for  implementing  orders  or  directives.  All  or  part  of  this 
authority  may  be  transferred  or  delegated”  [NATO  Standardization  Agency,  2008:  2-C- 
14].  Finally,  NSA  defines  command  and  control  system  as  “An  assembly  of  equipment, 
methods  and  procedures  and,  if  necessary,  personnel,  that  enables  commanders  and  their 
staffs  to  exercise  command  and  control”  [NATO  Standardization  Agency,  2008:  2-C-9]. 

Review  of  published  texts  and  doctrine  provides  the  systems  engineer  with  an 
understanding  of  what  command  and  control  is  and  has  been,  but  does  not  necessarily 
enable  the  systems  engineer  to  understand  what  command  and  control  will  be  when 
command  and  control  systems  being  designed  now  become  operational.  New  theories 
and  concepts  of  warfare,  in  conjunction  with  new  technologies,  all  impact  the  design,  use, 
and  evaluation  of  command  and  control  systems.  Two  concepts  -  Network-Centric 
Warfare  and  Cooperative  Engagement  Capability  -  demonstrate  the  potential  future  of 
command  and  control  and  are  reviewed  in  the  following  sections. 
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C.  CONCEPT  OF  NETWORK-CENTRIC  WARFARE 

Network-Centric  Warfare  (NCW)  is  a  concept  of  warfare  which  emerged  as  a 
result  of  the  revolution  in  information  and  communications  technology  which  occurred  in 
the  1990s.  NCW  is  a  framework  in  which  the  missions,  strategies,  tactics,  techniques, 
procedures,  and  organizations  available  to  a  networked  force  can  be  viewed  [Director, 
Force  Transformation,  OSD,  2005:  3;  Alberts,  Garstka,  &  Stein,  1999:  87-88].  NCW 
also  provides  the  networked  force  a  framework  in  which  the  rules  and  constraints  of 
warfare  can  be  reviewed,  reevaluated,  and  possibly  redefined.  Essentially  the  inputs  to, 
the  outputs  from,  and  the  objectives  of  a  command  and  control  system  can  now  be 
viewed  and  analyzed  with  this  new  concept  of  warfare. 

The  concept  of  NCW  consists  of  a  collection  of  ideas  such  as  geographically 
dispersed  forces,  shared  awareness,  speed  of  command,  self-synchronization,  and  virtual 
collaboration  [Alberts,  Garstka,  &  Stein,  1999:  87-114].  A  discussion  of  each  of  these 
ideas  is  beyond  the  scope  of  this  thesis.  However,  the  idea  with  arguably  the  greatest 
impact  on  this  thesis  and  on  the  traditionally  accepted  views  of  command  and  control  is 
self-synchronization.  Self-synchronization,  as  discussed  by  Cebrowski  and  Garstka 
[1998],  is  the  ability  of  the  networked  force  to  “organize  and  synchronize  complex 
warfare  activities  from  the  bottom  up.  The  organizing  principles  are  unity  of  effort, 
clearly  articulated  commander's  intent,  and  carefully  crafted  rules  of  engagement.” 
Though  Cebrowski  and  Garstka  argue  that  self-synchronization  requires  unity  of  effort 
and  commander’s  intent,  Alberts  and  Hayes  contend  that  “Successfully  accomplishing 
the  functions  of  Command  and  Control  does  not  necessarily  require:  Unity  of  command 
(an  individual  in  charge);  Unity  of  intent  (an  intersection  of  goals);  Hierarchical 
organizations;  Explicit  control”  [2006:  9].  Alberts  and  Hayes  conclude  “intent  may  or 
may  not  be  (1)  explicitly  communicated,  (2)  consciously  or  formally  accepted,  or  (3) 
widely  shared”  via  an  example  of  NATO  C3,  where  the  first  C  refers  to  consultation  and 
where  it  is  common  that  no  supreme  authority  can  determine  intent  [2006:  37]. 
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D.  CONCEPT  OF  COOPERATIVE  ENGAGEMENT  CAPABILITY 

Cooperative  Engagement  Capability  (CEC)  is  a  networked  approach  to  air 
defense.  “The  CEC  was  developed  in  response  to  the  need  to  maintain  and  extend  Fleet 
air  defense  against  advanced,  next-generation  threats  as  well  as  to  complement  advances 
in  sensor  and  weapon  systems”  [The  Cooperative  Engagement  Capability,  1995:  394], 

In  practice,  CEC  connects  combat  and  C2  systems  onboard  a  platform,  called  a  net 
control  unit  (NCU),  with  a  Cooperative  Engagement  Processor  (CEP).  The  CEP  is  then 
connected  to  a  Data  Distribution  System  (DDS)  onboard  the  platform  which  in  turn 
connects  with  other  DDS  of  other  platforms.  The  CEC  process  begins  when  raw  sensor, 
weapon,  and  C2  data  is  transmitted  from  the  combat  or  C2  system  to  the  NCU’s  CEP. 

The  CEP  then  transmits  the  raw  data  to  DDS  which  in  turn  transmits  the  raw  data  to  other 
connected  DDSs  onboard  other  NCUs.  Those  DDSs  then  transmit  the  raw  data  to  their 
respective  CEPs.  The  CEPs  then  process  the  raw  data  received,  either  from  systems 
onboard  the  NCU  or  from  other  NCUs,  and  disseminate  the  processed  data  to  applicable 
systems  [The  Cooperative  Engagement  Capability,  1995]. 

The  power  of  CEC  is  a  result  of  its  three  principles  -  Composite  Tracking; 
Precision  Cueing;  and  Coordinated,  Cooperative  Engagement.  With  CEC,  shared  radar 
data  is  processed  independently  on  each  NCU  into  composite  tracks  “with  input  data 
appropriately  weighted  by  the  measurement  accuracy  of  each  sensor  input”  [The 
Cooperative  Engagement  Capability,  1995:  378],  Thus,  if  sensors  onboard  a  NCU  lose  a 
contact,  other  NCUs  can  provide  the  necessary  data  for  tracking.  This  ability  is  referred 
to  as  Composite  Tracking.  Additionally,  an  NCU  can  initiate  actions  for  onboard 
systems  to  secure  a  local  track  if  the  received  data  concerning  a  contact  meet  the 
established  threat  requirements  [The  Cooperative  Engagement  Capability,  1995:  379]. 
This  capability  is  referred  to  as  Precision  Cueing  and  enables  the  local  acquisition  range 
to  be  greatly  extended.  Finally,  an  NCU  “may  fire  a  missile  and  guide  it  to  intercept  a 
target,  even  a  maneuvering  one,  using  radar  data  from  another  CEC  unit  even  if  it  never 
acquires  the  target  with  its  own  radars”  [The  Cooperative  Engagement  Capability,  1995: 
379].  “Moreover,  a  coordination  doctrine  may  be  activated  by  the  designated  NCU  for 
automated  engagement  recommendations  at  each  unit  based  on  force-level  engagement 
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calculations”  [The  Cooperative  Engagement  Capability,  1995:  380],  This  capability  is 
referred  to  as  Coordinated,  Cooperative  Engagement. 

CEC  has  been  developed  and  implemented  over  a  period  of  several  decades  for 
use  in  air  defense,  but  the  concept  can  easily  be  extended  to  other  warfare  areas  such  as 
anti-submarine  warfare,  surface  warfare,  and  ballistic  missile  defense.  In  fact,  Perry, 
Button,  Bracken,  Sullivan,  and  Mitchell  [2002]  present  and  analyze  scenarios  concerning 
the  application  of  CEC  to  the  first  and  last  example  warfare  areas.  Their  CEC  scenarios 
highlight  the  impact  of  self-synchronization  on  a  military  force’s  effectiveness. 

The  textual,  doctrinal,  and  near-future  concepts  reviewed  in  this  and  previous 
sections  have  presented  a  small  set  of  the  influences  on  stakeholders’  view  of  command 
and  control.  The  review,  however,  has  not  necessarily  brought  the  reader  closer  to  any 
true  understanding  of  the  topic  and  may  have  in  fact  induced  more  confusion  in  the 
process.  Given  that  an  aim  of  this  thesis  is  to  reduce  the  confusion,  it  becomes  necessary 
to  discuss  the  view  of  command  and  control,  no  matter  how  rudimentary,  derived  from 
the  above  review  and  utilized  during  research. 

E.  NAVAL  TACTICAL  COMMAND  AND  CONTROL 

When  a  specific  entity  is  designated  responsible  for  the  accomplishment  of  a 
mission,  command  is  a  function  by  which  the  responsible  entity  takes  inputs  (e.g., 
mission  objective,  assigned  forces,  operating  environment,  adversary’s  capabilities)  to 
produce  the  desired  output  (e.g.,  accomplishment  of  the  mission  objective).  Command 
and  control  is  the  process  by  which  the  inputs  generate  the  outputs.  A  command  and 
control  system  is  the  means  by  which  the  process  is  executed.  When  there  is  no  specific 
entity  designated  responsible  for  the  accomplishment  of  a  mission,  the  command  and 
control  process  and  the  command  and  control  system  can  still  take  inputs  to  produce  the 
desired  output.  In  such  a  case,  inputs  such  as  mission  objective  may  be  generated  during 
the  command  and  control  process  or  never  generated  at  all. 
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Figure  8.  Command  and  Control:  Function-Process-System 

Such  concept  of  function-process-system  is  similar  to  that  presented  by  Sweeney 
[2002].  Sweeney  contends  that  command  is  a  function  implemented  via  the  command 
and  control  process  supported  by  command  and  control  systems.  In  particular,  he 
describes  the  command  and  control  process  as  consisting  of  people,  infonnation,  and 
structure  (e.g.,  organization).  Unfortunately,  his  view  of  command  and  control,  primarily 
the  process,  is  inconsistent  with  common  definition  and  his  references.  First,  a  process  is 
“a  series  of  actions  or  operations  conducing  to  an  end”  [Mish,  1994:  929].  Of  people, 
information,  and  organization,  only  organization  could  be  considered  a  component  of  the 
command  and  control  process  and  then  only  if  the  concept  of  organization  included 
procedures.  Second,  Van  Creveld  argues  that  what  command  does  remains  constant,  but 
the  means  by  which  command  is  executed  changes  with  time  [1985:  9].  In  other  words, 
the  command  and  control  process  remains  constant  but  command  and  control  systems  are 
subject  to  change.  People,  information,  and  organization  do  not  remain  constant  and 
therefore  cannot  be  components  of  the  command  and  control  process.  Third,  including 
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people,  information,  and  organization  within  the  command  and  control  process  blatantly 
contradicts  the  U.S.  Marine  Corps  [MCDP  6,  1996:  52]  and  the  U.S.  Navy  [NDP  6,  1995 
6]  view  that  such  things  are  components  of  the  command  and  control  system. 

F.  CHAPTER  SUMMARY 

Command  and  control  is  an  enigma.  It  is  comprised  of  physical,  measurable 
factors  as  well  as  moral,  immeasurable  factors.  It  is  a  function.  It  is  a  process.  It  is  a 
system.  Portions  of  it  remain  constant  throughout  time  while  other  portions  are 
constantly  subject  to  change.  Successful  command  and  control  requires  mastery,  or  at 
least  a  deep  understanding,  of  the  controllable  and  uncontrollable  forces  of  war. 
Ignorance  of  what  command  and  control  is  considered  to  be  can  be  a  detriment  to  the 
systems  engineer. 

The  purpose  of  the  preceding  chapter  was  to  provide  a  basic  overview  of 
stakeholders’  past,  present,  and  future  concepts  of  command  and  control  in  order  to 
facilitate  communication  between  systems  engineers  and  system  stakeholders.  The 
review  serves  as  one  means  of  interaction  with  stakeholders.  The  review  also  provides  a 
common  vocabulary  for  discussion.  Though  the  value  of  the  review  may  not  be  apparent 
to  the  reader  at  this  time,  many  of  the  concepts  presented  in  this  chapter  will  impact  the 
systems  engineering  process  presented  in  subsequent  chapters. 
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III.  OVERVIEW  OF  SYSTEMS  ARCHITECTURE  PROCESS 


A.  INTRODUCTION 

The  three  primary,  conceptual  systems  engineering  life-cycle  phases  are  system 
definition,  system  development,  and  system  deployment  [Sage  &  Armstrong,  2000:  49]. 
The  architectural  phases  of  the  system  engineering  process  encompass  the  system 
definition  and  the  initial  portion  of  system  development.  The  methodology  of 
architectural  phases  for  this  thesis  followed  the  system  engineering  process  developed  by 
Alexander  Levis  and  presented  by  Buede  [2000]  and  Levis  and  Wagenhals  [2000].  The 
process  starts  with  the  operational  concept,  moves  to  the  co-development  of  the 
functional  architecture  and  the  physical  architecture,  and  concludes  with  the  development 
of  the  operational  architecture. 


Figure  9.  Architecture  Development  [from  Buede,  2000:  20] 

B.  OPERATIONAL  CONCEPT 

The  operational  concept,  as  presented  in  Buede  [2000],  is  a  general  vision  of  the 
system  from  the  view  of  the  system’s  stakeholders  and  includes  a  collection  of  scenarios 
(both  employment  and  life  scenarios);  a  graphical  model  describing  the  system,  its 
boundaries,  and  its  inputs  and  outputs;  objectives  for  the  system;  and  requirements  of  the 
system.  To  begin  the  development  of  the  operational  concept,  a  collection  of  scenarios  is 
generated.  The  collection  of  the  scenarios  should  span  the  entire  life  cycle  of  the  system 
and  should  include  all  relevant  stakeholders  during  each  phase  of  the  system’s  life  cycle. 
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Buede  [2000:  140]  explains  that  scenarios  should  include  “the  relevant  inputs  to  and 
outputs  from  the  system  and  the  other  systems  that  are  responsible  for  those  inputs  and 
outputs.” 

The  initial  scenarios  developed  should  be  as  simple  as  possible  and  from  the  view 
of  the  key  stakeholder,  then  expanding  the  collection  to  include  more  stakeholders, 
complexity  of  interactions,  and  phases  of  the  system’s  life  cycle  [Buede,  2000:  141]. 
Generated  scenarios  should  fall  into  two  general  categories  -  life  scenarios  and 
employment  scenarios.  Employment  scenarios  describe  the  employment  of  the  system, 
the  operational  use  of  the  system.  Life  scenarios  encompass  all  of  the  non-operational 
facets  of  the  system  throughout  its  life-cycle.  These  two  categories  are  akin  to  the  life 
and  sortie  missions  developed  by  Hunger,  as  presented  in  Buede  [2000],  and  align  with 
Van  Creveld’s  discussion  on  the  types  of  responsibilities  of  command. 

First  command  must  arrange  and  coordinate  everything  an  anny  needs  to 
exist  -  its  food  supply,  its  system  of  military  justice,  and  so  on.  Second, 
command  enables  the  army  to  carry  out  is  proper  mission,  which  is  to 
inflict  the  maximum  amount  of  death  and  destruction  on  the  enemy  within 
the  shortest  possible  period  of  time  and  at  a  minimum  loss  to  itself.  [Van 
Creveld,  1985:  6] 

In  addition  to  employment  and  life  scenarios,  the  systems  engineer  should  also  develop 
scenarios  describing  the  validation  and  acceptance  testing  of  the  system  throughout  its 
life-cycle. 

Development  of  scenarios  is  done  to  assist  in  defining  the  system,  which  includes 
establishing  external  systems  which  interact  with  the  system  and  identifying  those 
portions  of  the  context  which  impact  the  system  and  the  associated  external  systems. 

Even  if  initial  scenario  development  is  focused  on  key  stakeholders,  the  system  engineer 
is  still  faced  with  determining  the  extent  of  the  system.  Developing  scenarios  assists  in 
defining  the  system  and,  to  a  degree,  an  understanding  of  what  the  system  is  assists  in 
developing  the  scenarios.  A  refined  problem  statement,  effective  need,  or  intended 
design  goal  of  the  system  in  question  may  assist  the  further  development  of  scenarios. 

The  collection  of  developed  scenarios  and  the  refined  problem  statement,  when 
applicable,  serve  as  inputs  for  the  development  of  the  external  systems  diagram.  The 
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scenarios  and  problem  statement  need  not  be  in  final  form,  for  the  entire  systems 
engineering  process  is  iterative.  Input  is  taken  from  stakeholders  throughout  the  process 
and  the  operational  concept  is  updated  accordingly.  Just  as  the  refined  problem  statement 
assists  scenario  development  by  better  defining  what  the  system  is,  so  too  does  the 
external  systems  diagram. 

The  purpose  of  the  external  systems  diagram  is  to  define  the  boundaries  of  the 
system  for  all  stakeholders  of  the  system.  First,  a  basic  external  systems  diagram  is 
developed  based  on  the  work  of  Levis,  as  presented  by  Buede  [2000:  124-125].  The 
basic  external  systems  diagram  is  composed  of  three  parts  -  the  system,  the  external 
system(s),  and  the  context.  External  systems  interact  with  one  or  more  of  the  system’s 
subsystems  by  providing  inputs,  receiving  outputs,  or  both.  The  context  is  the  collection 
of  entities  which  can  influence  the  system  but  not  be  influenced  by  the  system. 

Details  concerning  the  inputs  and  outputs  of  the  system  as  well  as  the  interfaces 
between  parts  are  not  included  in  the  basic  external  systems  diagram.  The  basic  external 
systems  diagram  is  meant  to  assist  visualization  and  communication  between 
stakeholders  and  the  systems  engineer  and  to  develop  a  common  definition  of  the  system. 
An  example  of  a  basic  external  systems  diagram  is  presented  in  Figure  10. 
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CONTEXT 


Figure  10.  Basic  External  Systems  Diagram  [after  Buede,  2000:  124] 

During  scenario  development  and  the  drawing  of  the  basic  external  systems 
diagram,  several  key  interactions  of  the  system  with  external  systems  and  contexts  are 
identified  but  are  not  detailed.  Details  concerning  such  interactions  are  necessary  before 
an  explicit  external  systems  diagram  can  be  completed.  There  are  multiple  methods  for 
detailing  the  interactions  of  the  system  with  external  systems  and  contexts  [Buede,  2000: 
141-143;  Bruegge  and  Dutoit,  2004:  59-62].  The  system  engineer  then  combines  the 
details  of  the  interaction  diagrams,  no  matter  the  type  chosen,  with  the  basic  external 
systems  diagram  to  form  the  external  systems  diagram.  An  example  of  an  interaction 
diagram  is  presented  in  Figure  1 1 . 
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Figure  11.  Example  Interaction  Diagram  [after  Bruegge  &  Dutoit,  2004:  60] 

From  the  developed  scenarios  and  refined  problem  statement,  and  concurrently 
with  the  development  of  the  external  systems  diagram,  the  systems  engineer  develops  the 
systems  objectives  hierarchy.  The  purpose  of  the  systems  objectives  hierarchy  is  to 
organize  the  system’s  objectives  from  the  view  of  value  to  the  stakeholders  [Buede,  2000: 
147].  Care  must  be  taken  to  understand  when  a  particular  objective  serves  as  a  means  to 
obtain  a  higher  objective  and  when  its  value  is  fulfilled  by  lower  means  objectives. 
Understanding  these  interactions  enables  the  system  engineer  to  properly  organize  the 
system’s  objectives  to  develop  the  fundamental  objective.  The  process  is  continued  with 
further  inputs  from  the  system’s  stakeholders  concerning  the  desired  values  of  the 
pertinent  objectives.  These  inputs  enable  the  system  engineer  to  develop  system 
measures  of  merit  to  finalize  the  objectives  hierarchy  [Buede,  2000:  146-149]. 

Requirements  are  developed  with  the  operational  scenarios,  external  systems 
diagram,  and  the  system  objectives  hierarchy  providing  inputs.  Buede  [2000]  organizes 
requirements  into  four  groups:  input/output  requirements,  system-wide  and  technology 
requirements,  trade-off  requirements,  and  qualification  requirements.  First,  each  input 
and  output  identified  during  the  development  of  and  included  in  the  external  systems 
diagram  must  have  one  or  more  requirements.  Rules  and  constraints  pertaining  to 
interface  constraints  are  included  as  input/output  requirements.  Second,  system-wide  and 
technology  requirements  pertain  “to  the  system  as  a  whole  and  not  to  specific  inputs  or 
outputs”  [Buede,  2000:  154].  This  group  of  requirements  includes  technology, 
suitability,  cost,  and  schedule  requirements.  Third,  trade-off  requirements  are  based 
solely  on  the  value  judgments  of  stakeholders.  Qualification  requirements  address  how 
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the  requirements  are  observed,  verified,  validated,  and  accepted  [Buede,  2000:  155-157] 
and  are  developed  to  ensure  the  system  which  is  built  is  properly  designed  and  is 
acceptable. 

After  verifying  the  feasibility  and  testability  of  the  requirements  developed,  the 
operational  concept  is  detailed  enough  to  enable  the  co-development  of  the  functional 
architecture  and  the  physical  architecture.  This  does  not  serve  as  the  final  form  of  the 
operational  concept,  for  it  will  be  repeatedly  refined  and  updated  during  the 
developments  of  the  functional,  physical,  and  operational  architectures.  The  operational 
concept,  in  whatever  fonn,  has  described  the  system  from  an  external  view  by  defining 
boundaries  of  the  system  and  identifying  inputs  to  and  outputs  from  the  system.  The 
purpose  of  the  next  phase  of  the  system  architecture  process  is  to  describe  how  the 
system  converts  the  inputs  into  the  desired  outputs  and  then  to  define  the  means  by  which 
it  does  so. 

C.  FUNCTIONAL  ARCHITECTURE 

A  function  is  a  process  that  takes  inputs  and  transforms  them  into  outputs  [Buede, 
2000:  178].  Recall  that  a  system  is  “a  set  of  components  (subsystems,  segments)  acting 
together  to  achieve  a  set  of  common  objectives  via  the  accomplishment  of  a  set  of  tasks” 
[Buede,  2000:  38].  A  system,  therefore,  is  defined  by  1)  its  set  of  objectives  and  2)  the 
functions  required  for  it  to  achieve  such  set  of  objectives.  The  purpose  of  the  functional 
architecture  is  to  describe  what  the  system  is  to  do  with  the  identified  inputs  to  produces 
the  desired  outputs.  The  functional  architecture  is  developed  in  an  iterative  process  of 
five  phases.  First,  the  functions  of  the  system  are  organized  into  a  hierarchy  through  a 
combination  of  decomposition  and  composition  approaches  [Buede,  2000:  182-183]. 
Second,  the  relationships  between  the  inputs  and  outputs  which  were  identified  during  the 
development  of  the  operational  concept  are  described.  The  first  and  second  steps  are 
conducted  in  conjunction  with  the  development  of  the  physical  architecture.  Third, 
system  stakeholders  are  solicited  for  opinions  concerning  the  draft  functional 
decomposition.  Fourth,  the  input  and  output  requirements  detennined  in  the  operational 
concept  are  traced  to  functions  and  data  elements  in  the  functional  architecture.  The  third 
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and  fourth  phases  are  conducted  during  the  operational  architecture  development. 

Finally,  as  the  operational  architecture  is  finalized,  fault  tolerance  and  security  functions 
are  incorporated  with  the  functional  architecture. 

The  first  phase  in  developing  the  functional  architecture  is  to  develop  a  hierarchy 
of  the  system’s  functions.  This  phase  is  conducted  in  conjunction  with  the  development 
of  the  initial  generic  physical  architecture.  To  develop  the  functional  hierarchy  the 
system  engineer  can  use  a  decomposition  approach,  composition  approach,  or  a 
combination  of  both  decomposition  and  composition.  Functions  of  subsystems  identified 
during  the  development  of  the  physical  architecture,  or  potentially  identified  in  the 
external  systems  diagram  development,  can  be  synthesized  to  develop  the  top-level 
functions  of  the  system.  Top-level  functions  identified  during  the  development  of  certain 
scenarios  can  be  analyzed  and  decomposed  as  well.  Buede  [2000:  183]  strongly  advises 
the  system  engineer  to  combine  both  approaches,  composition  and  decomposition,  to 
develop  the  functional  hierarchy. 

The  second  phase  in  developing  the  functional  architecture  is  to  describe  the 
relationships  between  inputs  and  outputs  of  the  system.  During  the  operational  concept, 
interaction  diagrams  are  developed  demonstrating  the  relationship  between  certain  inputs, 
outputs,  and  the  system.  During  this  phase,  these  relationships  are  further  detailed  to 
explain  the  process  (i.e.,  sequence  of  functions)  by  which  the  inputs  become  the  outputs. 
The  system  engineer  combines  the  details  of  the  interaction  diagrams  and  the  functional 
hierarchy.  There  are  various  methods  which  the  system  engineer  can  utilize  to  detail  or 
model  these  relationships.  Such  methods  include  functional  flow  block  diagrams,  data 
flow  diagrams,  N2  charts,  or  IEDF0  diagrams.  An  example  relationship  diagram  [after 
Buede,  2000:  Chapter  3;  Sage  &  Armstrong,  2000:  133-134]  is  presented  in  Figure  12. 
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Figure  12.  Example  Relationship  Diagram 
[after  Buede,  2000:  Chapter  3;  Sage  &  Armstrong  2000:  133-134] 

The  third  phase  of  the  functional  architecture  development  is  to  seek  feedback 
from  system  stakeholders  concerning  the  functional  decomposition.  Opinions  concerning 
the  generic  physical  architecture  should  also  be  solicited  given  its  simultaneous 
development  with  the  functional  hierarchy.  Also  during  this  phase  the  system  engineer 
should  begin  the  development  of  the  operational  architecture  [Buede,  2000:  180].  A 
primary  purpose  of  the  stakeholder  feedback  is  to  ensure  there  is  not  an  absence  of 
functionality  or  a  redundancy  of  functionality  in  the  functional  hierarchy. 

The  fourth  phase  of  the  functional  architecture  development  is  to  trace  the 
input/output  requirements.  The  engineer,  through  the  systems  design  process,  seeks  to 
develop  a  set  of  specifications  for  the  development  of  each  subsystem,  component,  and 
configurable  item.  The  purpose  of  this  phase  is  to  ensure  each  of  the  requirements 
developed  in  the  operational  concept  are  associated  with  all  of  their  applicable  functions. 
With  the  development  of  the  operational  architecture,  each  function’s  associated 
requirements  will  form  specifications  for  the  resources  identified  in  the  physical 
architecture. 
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The  final  phase  of  the  functional  architecture  development  is  the  incorporation  of 
fault  tolerance  and  security  functions.  All  systems  can  have  faults  which  can  cause  errors 
leading  to  failures  in  the  system.  However,  as  Buede  [2000:  205]  states,  functions  to 
detect  errors  “are  typically  not  part  of  the  initial  drafts  of  the  functional  architecture 
because  they  depend  to  a  significant  degree  on  the  physical  architecture;  as  a  result  these 
functions  are  often  added  once  the  operational  architecture  is  taking  shape.”  Just  as  with 
fault  tolerance  functions,  security  functions  depend  largely  on  the  physical  architecture 
and  should  be  added  once  the  operational  architecture  has  taken  shape.  Thus  the 
feedback  from  stakeholders  in  the  third  phase  and  feedback  from  the  operational 
architecture,  which  includes  fault  tolerance  and  security  functions,  is  what  causes  the 
functional  architecture  development  to  be  iterative.  Additionally,  fault  tolerance  and 
security  functions  may  highlight  additional  input/output  requirements  which  need  to  be 
traced. 

D.  PHYSICAL  ARCHITECTURE 

The  physical  architecture,  as  presented  by  Buede  [2000],  is  a  hierarchical 
description  of  the  resources  which  comprise  the  system.  A  purpose  of  the  physical 
architecture  is  to  provide  “resources  for  every  function  identified  in  the  functional 
architecture”  [Buede,  2000:  216].  The  development  of  the  physical  architecture  is  done 
in  parallel  with  the  functional  architecture  development.  The  first  phase,  then,  is  to 
develop  a  generic  physical  architecture  to  partition  resources  into  common  categories 
based  on  the  functions  identified  in  the  functional  architecture.  Once  this  is 
accomplished,  a  set  of  instantiated  physical  architectures  is  developed  to  assist  the 
development  of  the  operational  architecture.  As  Buede  [2000:  218]  explains,  an 
instantiated  physical  architecture  is  a  generic  physical  architecture  with  perfonnance 
characteristics  of  the  system  resources  included. 

To  understand  the  difference  between  generic  and  instantiated  physical 
architectures  assume  the  system  under  consideration  is  a  wrist  watch.  One  generic 
component  of  the  wrist-watch  is  a  time  presentation  component.  The  instantiated 
physical  architecture  would  include  details  concerning  the  time  presentation  component 
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such  as  whether  it  is  an  audio  presentation  or  visual  display,  it  is  analog  or  digital,  or 
whether  it  displayed  12-hour  notation  or  24-hour  notation.  The  level  of  detail  for  the 
attributes  and  performance  characteristics  is  pertinent  to  the  system  under  design. 

Once  the  generic  physical  components  are  identified,  the  next  step  is  to  specify 
attributes  and  performance  characteristics  for  each  of  the  generic  components  from  which 
alternative  instantiated  physical  architectures  can  be  designed  and  selected.  There  are 
many  techniques  for  generating  numerous  physical  architecture  alternatives.  The 
morphological  box  technique,  suggested  by  Buede  [2000:  222-226],  is  one  method  for 
developing  the  physical  architecture  alternatives.  “In  the  two-dimensional  version  a  table 
is  created  with  columns  (or  sometimes  the  rows)  pertaining  to  the  generic  components  of 
the  physical  architecture.  Then  the  elements  of  each  column  are  filled  with  competing 
specific  instantiations  of  each  component”  [Buede,  2000:  223].  An  example 
morphological  box  for  a  wrist  watch  is  presented  in  Table  3. 


Wrist  Band 

Time  of  Day 
Presentation 

Chronograph 

Presentation 

Alarm 

Power 

Controls 

Metal  Links 

Digital 

Digital 

Audio 

Replaceable 

Battery 

Buttons 

Metal  w/  Clasp 

Analog 

Analog 

Alann 

Solar-Charge 

Battery 

Infra-red 

Plastic  w/  Clasp 

Audio 

Motion-Charge 

Battery 

Blue-tooth 

Velcro 

Braile 

Wound  Spring 

Table  3.  Example  Morphological  Box  -  Wrist  Watch 

In  addition  to  describing  the  physical  resources  which  comprise  the  system,  the 
physical  architecture  also  describes  the  procedures  by  which  the  system  is  used  [Buede, 
2000,  218].  Similar  to  the  physical  components,  procedures  and  controls  for  the  system 
can  have  multiple  instantiations.  When  feasible,  the  system  engineer  should  use 
creativity  techniques  such  as  the  morphological  box  to  generate  multiple  instantiations. 
Once  multiple  instantiations  are  created  for  all  generic  physical  components  and  all 
applicable  procedures  of  the  system,  the  system  engineer  should  develop  multiple 
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alternative  physical  architectures.  These  candidate  physical  architectures  will  serve  as  an 
input  for  the  operational  architecture  development. 


E.  OPERATIONAL  ARCHITECTURE 

The  operational  architecture  provides  a  description  of  the  system  design, 
incorporating  the  products  of  the  operational  concept,  functional  architecture,  and 
physical  architecture.  The  major  phases  of  the  operational  architecture  development  for 
this  thesis  were  to  allocate  functions  and  requirements  to  the  physical  components, 
describe  the  activation  and  control  of  functions,  and  to  conduct  an  analysis  of  the  design. 

The  first  step  in  the  development  of  the  operational  architecture  is  the  allocation 
of  functions  from  the  functional  architecture  to  components  from  the  physical 
architecture.  The  initial  phases  of  this  process  are  conducted  in  conjunction  with  the  co¬ 
development  of  the  functional  hierarchy  and  the  generic  physical  architecture.  The 
collection  of  relationship  diagrams  developed  for  the  functional  architecture  account  for 
this  step  if  generic  physical  components  were  identified  in  the  diagrams.  If  they  were 
not,  the  systems  engineer  should  accomplish  such  during  the  first  step  of  the  operational 
architecture  development. 

The  second  step  in  the  development  of  the  operational  architecture  is  to  define 
and  analyze  functional  activation  and  control  structures.  The  collection  of  relationship 
diagrams  is  refined  for  each  of  the  alternative  physical  architectures,  incorporating  the 
instantiated  physical  components  and  procedures  for  each.  The  functional  activation  and 
control  can  be  further  detailed  through  the  generation  table.  An  example  functional 
activation  and  control  table  for  the  relationship  diagram  presented  in  Figure  12.  is  shown 
below  in  Table  4. 


Function 

Output 

Required  Inputs 

Required  Controls 

Output  1 

-  Output  3 

-  Control  2 

Function  1 

Output  2 

-  Input  1 

-  Control  1 

-  Control  2 

Function  2 

Output  3 

-  Output  2 

-  Input  2 

-  Control  3 

Table  4.  Example  Functional  Activation  and  Control  Table 
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The  third  step  in  the  development  of  the  operational  architecture  is  to  conduct  an 
analysis  of  the  proposed  design  or  set  of  designs.  The  system  analysis  consists  of  both 
performance  analyses  and  risk  analyses  [Buede,  2000:  267].  In  many  cases  these 
analyses  are  conducted  through  modeling  and  simulation.  Once  the  system  analysis  is 
completed,  the  systems  engineer  then  documents  the  architectures  for  approval  by 
stakeholders. 

F.  CHAPTER  SUMMARY 

The  methodology  of  architectural  phases  for  this  thesis  followed  the  system 
engineering  process  developed  by  Alexander  Levis  and  presented  by  Buede  [2000]  and 
Levis  and  Wagenhals  [2000],  The  process  starts  with  the  operational  concept,  moves  to 
the  co-development  of  the  functional  architecture  and  the  physical  architecture,  and 
concludes  with  the  development  of  the  operational  architecture. 

The  operational  concept  is  a  general  vision  of  the  system  from  the  view  of  the 
system's  stakeholders.  The  functional  architecture  describes  what  the  system  is  to  do 
with  the  identified  inputs  to  produce  the  desired  outputs.  The  physical  architecture 
describes  the  resources  which  comprise  the  system  and  the  associated  procedures. 
Finally,  the  operational  architecture  provides  a  description  of  the  system  design, 
incorporating  the  products  of  the  operational  concept,  functional  architecture,  and 
physical  architecture.  The  following  chapters  present  the  architectural  phases  conducted 
for  defining  and  developing  a  conceptual  command  and  control  system  for  tactical  naval 
units. 
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IV.  OPERATIONAL  CONCEPT 


A.  INTRODUCTION 

The  operational  concept,  as  presented  in  Buede  [2000],  is  a  general  vision  of  the 
system  from  the  view  of  the  system's  stakeholders  and  includes  a  collection  of  scenarios 
(both  employment  and  life  scenarios);  a  graphical  model  describing  the  system,  its 
boundaries,  and  its  inputs  and  outputs;  objectives  for  the  system;  and  requirements  of  the 
system.  Development  of  the  operational  concept  also  produces  a  common  vocabulary  to 
facilitate  communication  between  the  systems  engineer  and  stakeholders.  During 
development  of  the  operational  concept,  the  system  should  be  viewed  as  a  black-box. 
How  the  system  converts  inputs  to  desired  outputs  and  the  means  by  which  this  is  done 
will  be  considered  during  the  functional  architecture  and  physical  architecture 
development.  This  chapter  presents  the  key  phases  and  products  within  the  operational 
concept  development.  Appendix  A:  Scenario  Development,  Appendix  C:  External 
Systems  Diagram,  and  Appendix  D:  System  Objectives  provide  more  details  of  the 
operational  concept  development  process  outside  those  presented  in  this  section. 

B.  SCENARIOS 

To  begin  the  development  of  the  operational  concept,  a  collection  of  scenarios 
was  generated.  Scenario  development  serves  as  the  initial  step  for  stakeholders  and 
engineers  to  come  to  a  common  definition  of  the  system.  In  practice,  the  collection  of  the 
scenarios  should  span  the  entire  life  cycle  of  the  system  and  should  include  all  relevant 
stakeholders  during  each  phase  of  the  system’s  life  cycle.  Additionally,  the  collection  of 
generated  scenarios  should  fall  into  two  general  categories — life  scenarios  and 
employment  scenarios.  Employment  scenarios  describe  the  operational  use  of  the 
system.  Life  scenarios  encompass  all  of  the  non-operational  facets  of  the  system 
throughout  its  life-cycle. 

Since  the  focus  of  this  thesis  was  on  the  operational  employment  of  a  naval 
tactical  command  and  control  system,  only  employment  scenarios  were  developed.  Life 
scenarios,  validation  scenarios,  and  acceptance  testing  scenarios  were  not  developed. 
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Potential  employment  scenarios  for  naval  tactical  forces,  however,  are  numerous.  Hayes, 
Krulisch,  and  White  [2008]  conducted  an  analysis  of  historical  and  current  naval  texts 
and  strategies  to  develop  a  list  of  potential  objectives  for  future  naval  forces.  A  further 
decomposition  of  the  analysis  was  conducted  to  generate  missions  for  which  future  naval 
forces  may  be  employed.  These  missions,  or  employment  scenarios,  include: 

1 .  Secure  local  sea  control 

1.1.  Gain  and  maintain  local  sea  access 

1.1.1.  Conduct  Mine  Sweeping  Operations 

1.1.2.  Conduct  Anti-submarine  Operations 

1.2.  Deny  local  sea  access 

1.2.1.  Conduct  Mine  Laying  Operations 

1.2.2.  Conduct  undersea,  surface,  and  air  patrols  of  local  sea 

1.3.  Defeat  adversary’s  fleet 

1.3.1.  Provide  defense  of  forces 

1.3. 1.1.  Maneuver  Forces 

1.3. 1.2.  Prosecute  Contacts 

1.3. 1.3.  Engage  Threats 

1.3.2.  Conduct  attack  on  adversary’s  forces 

1. 3.2.1.  Maneuver  Forces 

1.3.2. 2.  Prosecute  Contacts 

1.3. 2. 3.  Engage  Targets 

1.3. 2. 3.1.  Engage  Planned  Targets 

1.3. 2. 3. 2.  Engage  Dynamic  Targets 

1.4.  Gain  intelligence  of  the  local  sea 

1.4.1.  Collect  information  concerning  the  local  sea 

1 .4. 1 . 1 .  Conduct  surveillance  of  the  local  sea 

1.4. 1.2.  Conduct  reconnaissance  of  the  local  sea 

1.4.2.  Process/integrate/evaluate/analyze/interpret  infonnation  to 
produce  intelligence  of  the  local  sea 

2.  Patrol  Sea  Lines  of  Communication 

3.  Seabed  Defense 

4.  Escort 

4.1.  Commerce  Convoy  Escort 

4.2.  Military  Convoy  Escort 

5.  Provide  land  defense 

5.1.  Maritime  Ballistic  Missile  Defense 

5.2.  Mine  Defense 

6.  Conduct  land  attack 

6.1.  Naval  Fires  Support 

6.2.  Strategic  Missile  Deployment 

7.  Maritime  Interdiction 

8.  Maritime  Security 

9.  Maritime  Domain  Awareness 
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9.1.1.  Collect  information  concerning  the  global  seas  which  may 
impact  U.S.  security,  safety,  economy,  or  environment 

9. 1 . 1 . 1 .  Conduct  surveillance  of  the  global  seas  which  may  impact 
U.S.  security,  safety,  economy,  or  environment 

9. 1 . 1 .2.  Conduct  reconnaissance  of  the  global  seas  which  may 
impact  U.S.  security,  safety,  economy,  or  environment 

9.1.2.  Process/integrate/evaluate/analyze/interpret  infonnation  to 
produce  intelligence  of  the  global  seas  which  may  impact  U.S. 
security,  safety,  economy,  or  environment 

10.  Humanitarian  Assistance  and  Disaster  Response 

10.1.  Provide  heavy  lift  support 

10.2.  Provide  ship-to-shore  lift 

10.3.  Provide  search  and  rescue  support 

Given  the  range  of  missions  future  naval  tactical  forces  face,  the  employment 
scenario  development  was  further  narrowed  to  encompass  only  the  mission  of  securing 
local  sea  control.  The  composition  of  naval  tactical  forces  employed  in  securing  local  sea 
control  can  vary  from  operation  to  operation  and  has  a  significant  impact  on  the  scope  of 
developed  scenarios.  A  single  submarine  and  a  large  Carrier  Strike  Group  can  both  be 
used  to  secure  local  sea  control,  though  the  capabilities  and  methods  of  both  are  vastly 
different.  Therefore,  the  development  of  the  employment  scenarios  focused  on  those 
actions  a  Surface  Action  Group  (SAG)  would  conduct  in  order  to  secure  local  sea  control. 

1,  Settings 

Once  the  focus  of  the  scenario  development  had  sufficiently  been  narrowed,  three 
settings  were  created.  Each  of  the  settings  included  at  least  two  warfare  or  operational 
tasks  (air  defense,  antisubmarine  warfare,  etc.)  which  a  SAG  could  be  expected  to 
conduct  while  securing  local  sea  control.  The  settings  served  as  foundations  on  which 
the  remaining  portions  of  the  scenarios  were  developed.  The  three  settings  are  presented 
in  Appendix  A:  Scenario  Development. 

2.  Scenarios 

Once  the  three  settings  were  finished,  scenario  development  continued  by 
identifying  system  stakeholders,  including  interacting  systems.  A  key  stakeholder  was 
identified  from  the  initial  set  of  stakeholders  which,  for  all  of  the  settings,  was  the  Officer 
in  Tactical  Command  (OTC)  of  the  SAG.  Initial  scenario  development  was  conducted 
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from  the  viewpoint  of  the  OTC  and  included  the  flow  of  events  as  seen  by  the  OTC  as 
well  as  the  pertinent  inputs  to  and  outputs  from  the  command  and  control  system.  As 
suggested  by  Buede  [2000:  141],  the  focus  was  not  on  the  details  of  how  the  system 
worked  but  rather  how  the  system  was  used  by  or  served  stakeholders.  The  process  was 
continued  for  all  of  the  identified  stakeholders  and  interacting  systems  to  ensure  all 
possible  inputs  to  and  outputs  from  the  command  and  control  system  were  identified.  A 
template  for  scenario  development  is  shown  in  Table  5.  A  collection  of  the  developed 
scenarios  is  presented  in  Appendix  A:  Scenario  Development.  A  majority  of  the  settings 
developed  included  dynamic  and  time-sensitive  targets.  Appendix  B:  Target 
Engagement  presents  the  engagement  process  model  used  during  scenario  development 
and  the  associated  terminology. 


SCENARIO 

Setting 

Systems  & 
Stakeholders 

Flow  of  events 

Inputs 

Outputs 

References 

Table  5.  Scenario  Development  Template 


3.  Refined  Problem  Statement 

The  “system”  in  question  was  the  command  and  control  system  for  naval  forces  at 
the  tactical  level  of  war.  Since  a  goal  of  this  thesis  was  to  assist  in  the  integration  of  net- 
centric  systems  and  net-centric  doctrine  to  meet  the  command  and  control  needs  of 
tactical  naval  forces,  a  review  of  publications  concerning  NCW  and  Network-Centric 
Operations  (NCO)  was  conducted  to  determine  potential  attributes  of  the  command  and 
control  system.  From  this  review,  a  refined  problem  statement  was  developed,  which  is: 

A  responsive  and  robust  command  and  control  system  which  connects 
dispersed  forces  and  enables  such  forces  to  self-synchronize  and  allocate 
resources  to  mass  effects  in  order  to  meet  the  established  intent  at  the 
tactical  level  of  war. 
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By  responsive  it  is  meant  the  timeliness  in  which  the  command  and  control 
system  can  identify  changing  circumstances  (e.g.,  threats  from  different  functional  areas, 
connectivity  of  the  forces,  etc.),  determine  the  impact  of  the  changing  circumstances,  and 
enact  an  appropriate  response  [after  Alberts  &  Hayes,  2006:  45].  By  robust  it  is  meant 
the  ability  of  the  command  and  control  system  to  identify  a  range  of  changing 
circumstances,  determine  the  impact  of  the  changing  circumstances,  and  enact  an 
appropriate  response  [after  JP  6-0,  2006:  Ch  I,  10].  The  traditional  view  of  dispersed 
forces,  primarily  in  early  NCW  writings,  focused  on  geographically  dispersed  forces. 
With  the  increased  discussion  in  the  general  press  on  “cyber-warfare”  and  infonnation 
operations,  the  view  of  dispersed  forces  must  also  include  dispersion  on  the  “network” 
which  connects  the  forces. 

Self-synchronization  is  the  ability  of  a  force  to  “organize  and  synchronize 
complex  warfare  activities  from  the  bottom  up”  [Cebrowski  &  Garstka,  1998].  This  self¬ 
synchronization  must  also  include  the  ability  for  the  forces  to  allocate  resources  at  their 
disposal  to  mass  effects  to  meet  the  established  intent.  Massing  effects  need  not  require 
the  massing  of  forces.  It  must  also  be  noted  that  the  effects  emphasized  exclude  strategic 
effects  (i.e.,  nuclear  weapons). 

Established  intent  is  used  instead  of  the  traditional  “commander’s  intent”  since 
self-synchronizing  forces,  which  may  not  be  connected  with  their  commander  or  may 
have  no  commander  (e.g.,  coalition  forces),  may  be  capable  identifying  and  responding  to 
emerging  circumstances  which  alter  the  operating  environment  and  their  purpose.  As 
Alberts  and  Hayes  [2006:  37]  discuss  “intent  may  or  may  not  be  (1)  explicitly 
communicated,  (2)  consciously  or  formally  accepted,  or  (3)  widely  shared.”  Finally,  the 
tactical  level  of  war  is  intended  to  be  the  traditional  functional  warfare  areas/missions 
(e.g.,  air  defense,  surface  warfare,  anti-submarine  warfare,  strike  warfare,  maritime 
interception,  etc.).  It  also  re-establishes  the  exclusion  of  strategic  weapons  from  the 
problem. 
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C.  EXTERNAL  SYSTEMS  DIAGRAM 

The  initial  collection  of  developed  scenarios  and  the  refined  problem  statement 
served  as  inputs  for  the  development  of  the  external  systems  diagram.  The  purpose  of  an 
external  systems  diagram  is  to  define  the  boundaries  of  the  system  and  describe  the 
interactions  with  the  system  for  all  applicable  stakeholders.  A  basic  external  systems 
diagram  is  developed  to  assist  in  the  definition  of  the  boundaries  of  the  system  and 
interaction  diagrams  are  developed  to  describe  stakeholder  interactions  with  the  system. 
The  products  of  these  steps  enable  the  development  of  the  external  systems  diagram. 
Details  concerning  the  development  of  the  external  systems  diagram  are  presented  in 
Appendix  C:  External  Systems  Diagram. 

1.  Basic  External  Systems  Diagram 

The  first  step  in  developing  the  external  systems  diagram  was  the  drawing  of  a 
basic  external  systems  diagram.  The  purpose  of  the  basic  external  systems  diagram  is  to 
assist  visualization  and  communication  between  stakeholders  and  the  systems  engineer  as 
well  as  for  developing  a  common  definition  of  the  system.  The  format  of  the  basic 
external  systems  diagram  used  in  this  thesis  is  based  on  the  work  of  Levis,  as  presented 
by  Buede  [2000:  38].  The  basic  external  systems  diagram  is  composed  of  three  parts  - 
the  system,  the  external  system(s),  and  the  context. 

•  System:  "A  set  of  components  (subsystems,  segments)  acting  together  to 
achieve  a  set  of  common  objectives  via  the  accomplishment  of  a  set  of 
tasks"  [Buede,  2000:  38]. 

•  External  Systems:  "A  set  of  entities  that  interact  with  the  system  via  the 
system's  external  interfaces"  [Buede,  2000:  38]. 

•  Context:  "A  set  of  entities  that  can  impact  the  system  but  cannot  be 
impacted  by  the  system"  [Buede,  2000:  38]. 

Details  concerning  the  inputs  and  outputs  of  the  system  as  well  as  the  interfaces  between 
parts  are  described  in  the  interaction  diagrams  and  are  therefore  not  included  in  the  basic 
external  systems  diagram. 
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As  in  discussed  in  Chapter  II,  the  author  adopted  the  concept  of  function-process- 
system  for  command  and  control.  First,  command  is  a  function  by  which  a  responsible 
entity  takes  inputs  to  produce  the  desired  output.  Second,  command  and  control  is  the 
process  by  which  the  inputs  generate  the  outputs.  Finally,  a  command  and  control  system 
is  the  means  by  which  the  process  is  executed. 

The  author  posits  that  people  are  a  component  of  the  command  and  control 
system,  information  is  what  flows  within  the  system,  and  organization  is  a  rule  or 
constraint  on  the  system.  This  version  of  the  concept  incorporates  ideas  of  Van  Creveld 
[1985],  the  U.S.  Marine  Corps  [MCDP  6,  1996],  and  the  U.S.  Navy  [NDP  6,  1995] 
among  many.  This  can  be  seen  with  the  two  major  component  categories  -  People  and 
the  Communications  &  Information  Systems.  The  inputs  to  and  outputs  from  the  system, 
along  with  the  cross-communication  between  subsystems,  are  Information.  The 
developed  basic  external  systems  diagram  is  presented  in  Figure  13. 

The  commander,  in  this  case  the  OTC,  is  not  considered  a  part  of  the  command 
and  control  system.  Since  the  command  and  control  system  is  the  means  by  which  the 
command  and  control  process  executes  the  function  of  command  for  the  commander,  the 
commander  is  not  a  component  of  system.  The  commander  is  an  external  system  which 
affects  the  command  and  control  process  and  interacts  with  the  command  and  control 
system.  If  during  the  command  and  control  process  a  decision  by  the  commander  is 
needed,  such  decision  is  an  input  to  the  command  and  control  system.  Additional 
discussion  concerning  the  basic  external  systems  diagram  is  presented  in  Appendix  C: 
External  Systems  Diagram. 
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CONTEXT 


Figure  13.  Basic  External  Systems  Diagram 

2.  Interaction  Diagrams 

During  scenario  development  and  the  drawing  of  the  basic  external  systems 

diagram,  several  key  interactions  of  the  system  with  external  systems  and  contexts  are 

identified  but  are  not  detailed.  Details  concerning  such  interactions  are  necessary  before 
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an  explicit  external  systems  diagram  can  be  completed.  There  are  multiple  methods  for 
detailing  the  interactions  of  the  system  with  external  systems  and  contexts.  Buede  [2000: 
141-143]  presents  the  input/output  trace  which  provides  a  sequential  representation  of 
one  stakeholder’s  or  one  external  system’s  interaction  with  the  system.  Bruegge  and 
Dutoit  [2004:  59-62]  present  two  other  types  of  interaction  diagrams,  namely  sequence 
diagrams  and  collaboration  diagrams.  Sequence  diagrams  are  essentially  input/output 
traces  which  can  depict  multiple  stakeholders  and/or  external  systems,  when  necessary. 
Collaboration  diagrams  present  the  interactions  numerically  (i.e.,  1,  2,  3,  etc.)  rather  than 
graphically. 

Due  to  the  complexities  of  scenarios  developed,  an  expanded  input/output  trace 
akin  to  the  sequence  diagram  presented  by  Bruegge  &  Dutoit  was  used  to  describe 
interactions  with  the  system.  As  described  earlier,  the  basic  external  systems  diagram 
presented  in  Figure  13.  is  a  result  of  the  function-process-system  concept  of  command 
and  control  adopted  by  the  author.  Additionally,  the  collection  of  interaction  diagrams 
presented  in  Appendix  C:  External  Systems  Diagram  extends  this  concept  and  show 

that  Information  serves  as  the  inputs  to  and  outputs  from  the  system  as  well  as  the  cross¬ 
communication  between  subsystems.  The  details  described  in  interaction  diagrams  are 
then  combined  with  the  basic  external  systems  diagram  to  form  the  external  systems 
diagram. 


3.  External  Systems  Diagram 

The  external  systems  diagram  expands  the  basic  external  systems  diagram  to 
include  the  inputs  and  outputs  detailed  in  interaction  diagrams.  The  purpose  of  the 
external  systems  diagram  is  to  model  the  “interaction  of  the  system  with  other  (external) 
systems  in  the  relevant  contexts,  thus  providing  a  definition  of  the  system’s  boundaries  in 
terms  of  the  system’s  inputs  and  outputs”  [Buede,  2000:  144].  The  external  systems 
diagram  is  presented  in  Figure  14. 
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Figure  14.  External  Systems  Diagram 
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NODE:  ALL  TITLE:  External  Systems  Diagram  for  Operational  Concept  NO.:  004 


D.  SYSTEM  OBJECTIVES  HIERARCHY 

The  purpose  of  the  systems  objectives  hierarchy  is  to  organize  the  system’s 
objectives  from  the  view  of  value  to  the  stakeholders  [Buede,  2000:  147].  Objectives 
exist  in  every  phase  of  the  system’s  life-cycle.  Types  of  objectives  can  include 
operational  perfonnance,  technical  performance,  operational  suitability,  cost,  schedule, 
and  risk.  The  focus  of  this  thesis  was  on  the  operational  employment  of  a  naval  tactical 
command  and  control  system.  Subsequently,  system  objective  development  focused  on 
operational  perfonnance  and  suitability.  Cost,  schedule,  and  risk  were  not  included. 

The  system  objectives  development  process  began  with  the  refined  problem 
statement,  developed  during  scenario  development,  serving  as  a  guide.  Keeney  [1992: 

56]  proposes  that  “The  most  obvious  way  to  identify  objectives  is  to  engage  in  a 
discussion  of  the  decision  situation.”  Since  publication  research  is  a  form  of  discussion, 
as  Booth,  Colomb  and  Williams  contend  [2008:  1 1],  numerous  publications  concerning 
measures  of  effectiveness,  operational  suitability,  C4ISR  system  capabilities, 
communications,  information  theory,  and  network-centric  warfare  were  reviewed  to 
determine  qualities  pertinent  to  a  network-centric  naval  tactical  command  and  control 
system.  In  conjunction  with  the  publication  review,  inputs  from  stakeholders  were 
solicited  to  assist  the  author  in  developing  and  organizing  the  system’s  objectives  and 
their  associated  measures  of  merit  (i.e.,  measures  of  effectiveness  and  their  associated 
measures  of  performance)  [Buede,  2000:  146-149]. 

The  system  objectives  generated  were  reorganized  over  several  iterations,  each 
time  reviewing  the  refined  problem  statement  to  ensure  stated  properties  were  accounted 
for  in  the  objectives  hierarchy.  The  top-level  of  the  system  objective  hierarchy  developed 
is  shown  in  Figure  15.  The  full  system  objective  hierarchy  and  description  are  presented 
in  Appendix  D:  System  Objectives  . 
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Figure  15.  Top-level  of  System  Objectives  Hierarchy 

Defoe  [1993:  7-8]  presents  seven  principles  for  developing  system  objectives. 
Three  of  Defoe’s  principles  were  of  particular  importance  during  this  phase  of  the  system 
development.  First,  the  objectives  should  have  “demonstrable  links  to 
customer/consumer  needs  and  system  requirements”  [DeFoe,  1993:  7].  This  principle 
aligns  with  the  essential  and  operational  attributes  identified  by  Keeney  [1992,  82-83]. 
The  publication  review,  in  conjunction  with  stakeholder  solicitation  via  online 
discussions  and  personal  communications,  served  as  the  methods  for  accomplishing  this 
principle.  Whenever  possible,  references  to  the  objectives  and  measures  were  retained  to 
maintain  the  traceability  of  stakeholder  need.  The  stakeholder  solicitation  also  served  as 
the  method  for  accomplishing  the  second  important  principle:  stakeholders  must  be 
allowed  to  “modify  requirements  and  participate  in  developing  the  solution”  [Defoe, 
1993:  8],  The  third  important  principle  is  that  objectives  should  be  measurable  and 
understandable  [DeFoe,  1993:  7,  Keeney,  1992:  82,  85].  In  alignment  with  the  principle 
of  developing  measurable  and  easily  understandable  objectives,  the  concept  of  Measures 
of  Merit  (MoM)  [after  NATO  Research  and  Technology  Organization,  2002:  Chapter  5], 
was  adopted. 

1,  Measures  of  Merit 

Measures  of  Merit  (MoM)  are  a  hierarchy  of  measures  which  serve  as  a  base  to 
compare  different  options.  Since  the  focus  of  this  thesis  was  on  naval  tactical  forces 
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tasked  with  securing  local  sea  control,  MoM  of  the  highest  level,  Measures  of  Policy 
Effectiveness  (MoPE),  were  not  considered.  Additionally,  Measures  of  Force 
Effectiveness  (MoFE)  were  not  considered. 

MoFE  measure  the  force’s  performance  in  a  mission  or  the  extent  to  which  the 
force  meets  its  objectives.  Mission  accomplishment  is  not  a  measure  of  the  command 
and  control  system  but  rather  the  force.  A  command  and  control  system  can  provide  the 
best  possible  situational  awareness  for  the  commander,  the  commander  can  make  the  best 
possible  decisions,  and  the  command  and  control  system  can  perfectly  convey  such 
decisions  to  the  force  but,  the  mission  can  still  fail  if  the  force  executes  the  decision 
poorly.  To  illustrate,  consider  an  air-defense  example.  A  commander,  with  the 
assistance  of  a  command  and  control  system,  can  make  the  best  decision  for  engaging  the 
air  threats  based  on  weapons  effectiveness  data  collected  during  testing.  If,  however,  the 
weapons  selected  fail  to  perfonn  at  the  effectiveness  level  determined  in  testing,  mission 
failure  cannot  necessarily  be  attributed  to  failure  in  the  command  and  control  system  or 
failure  by  the  commander.  The  removal  of  mission  accomplishment  from  the  quality 
measure  of  a  command  and  control  system  is  a  concept  further  discussed  by  Alberts  and 
Hayes  [2006:  Chapter  4]. 

The  MoM  levels  considered  for  this  thesis  included  Measures  of  C2  Effectiveness 
(MoCE),  Measures  of  Performance  (MoP),  and  Dimensional  Parameters  (DP).  MoCE 
focus  on  the  impact  of  C2  systems  within  the  operational  context.  MoP  measure  the 
performance  within  the  system  structure.  Finally,  the  lowest  level,  Dimensional 
Parameters  (DP),  measure  the  properties  or  characteristics  inherent  in  the  physical  parts 
of  the  C2  systems.  For  example,  the  capacity  of  a  particular  data  link  could  be  a  DP 
whereas  the  capacity  of  a  network  of  data  links  could  be  a  MoP.  Continuing,  the 
difference  between  needed  capacity  and  available  capacity  of  a  network  of  data  links  in  a 
given  situation  could  be  a  MoCE.  Finally,  percentage  of  targets  successfully  engaged 
could  be  a  MoFE.  It  is  a  general  rule  that  a  measure  higher  in  the  MoM  hierarchy  tends 
to  be  more  context,  task,  or  mission  specific  [NATO  Research  and  Technology 
Organization,  2002:  96]. 
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2. 


Selected  Measures  of  Merit 


Appendix  D:  System  Objectives  presents  the  full  system  objective  hierarchy. 
Measuring,  evaluating,  and  integrating  the  results  of  all  of  the  objectives  is  important  in 
the  development  of  a  command  and  control  system,  but  is  beyond  the  scope  of  this  thesis. 
Therefore,  with  the  refined  problem  statement  as  a  guide,  particular  MoM  were  selected 
as  key  measures  for  the  remaining  phases  of  the  network-centric  naval  tactical  command 
and  control  system  development.  The  key  MoM  selected  from  the  system  objectives 
hierarchy  are  presented  in  Table  6.  Further  discussions  concerning  the  selection  process 


are  detailed  in  Appendix  D:  System  Objectives  . 


1.2.1 

MoP 

Number  of  sources  confirming  information 

1.3.1 

MoP 

Time  between  changing  circumstances  and  observation 

1.3.2 

MoP 

Time  between  the  observation  and  the  completion  of  processing  the  data  into 
information 

1.3. 4. 4 

MoP 

Probability  of  shelf-life  is  less  than  time  between  updates 

1.4. 1.2 

MoP 

Percentage  of  nodes  which  are  capable  of  viewing  information 

1. 4.2.2 

MoP 

Percentage  of  nodes  which  are  capable  of  acting  on  information 

1.5. 2. 4 

MoP 

Percentage  of  Essential  Elements  of  Information  (EEI)  met 

1.5. 2. 5 

MoP 

Percentage  of  commander’s  Essential  Elements  of  Friendly  Information  (EEFI)  met 

1.8.1. 1 

DP 

Spatial  resolution  of  observation  capability 

1.8. 1.2 

DP 

Temporal  resolution  of  observation  capability 

1.9.2 

MoP 

Number  of  nodes  in  the  life  of  the  information  to  which  it  can  be  attributed 

1.9.1 

MoP 

Differential  between  time  information  is  received  by  a  node  and  when  information  can 
be  attributed 

2.1. 1.2 

MoP 

Percentage  of  total  decision-authorized  entities  that  are  available  via  existing 
relationships  and  connections 

2.1. 1.3 

MoP 

Percentage  of  total  allocation-authorized  entities  that  are  available  via  existing 
relationships  and  connections 

2.1. 1.4 

MoP 

Percentage  of  total  action-authorized  entities  that  are  available  via  existing  relationships 
and  connections 

2. 1.2. 1.2 

MoP 

Time  between  operational  failures  for  the  network  of  connections 

2.1.2.2.2 

MoP 

Probability  of  operational  failure  for  network  of  connections 

2.3.3. 1.2 

MoP 

Quantity  of  overflow  beyond  capacity  for  the  network  of  relationships  and  connections 

2.4.1. 1.4 

MoP 

Total  geographical  volume  of  relationships  and  connections 

2.4.2.1.3 

MoP 

Median  time  required  to  reconfigure  relationships  and  connections  to  meet  changing 
circumstances  and/or  necessary  responses 

2. 4. 2.2 

MoP 

Number  of  possible  solutions  for  required  reconfiguration  to  meet  changing 
circumstances  and/or  necessary  responses 

2.4.3. 1.4 

MoP 

Median  percentage  of  nodes  which  each  relationship  or  connection  is  capable  of 
connecting  with 

2.4.4. 1.3 

MoP 

Number  of  nodes  the  network  of  connections  are  capable  of  adding 

2.4. 4.2.7 

MoP 

Median  time  required  to  add  all  relationships  and  connections  to  meet  changing 
circumstances  and/or  necessary  responses 

2.4.5. 1.3 

MoP 

Median  geographical  range  nodes  can  maneuver  while  maintaining  needed  relationships 
or  connections 

3.2 

MoP 

Consistency  of  established  intent  between  forces 

4.2 

MoP 

Consistency  of  awareness  between  forces  of  rules  and  constraints  which  are  applicable 
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to  such  forces 

5.1.2 

MoP 

Consistency  of  response  with  established  intent 

5.1.4 

MoP 

Consistency  of  response  with  rules  and  constraints 

5.2.1 

MoP 

Time  between  receipt  of  information  concerning  changing  circumstances  and 
acknowledgement  of  receipt 

5.2.2. 1 

MoP 

Time  between  acknowledgement  of  receipt  of  information  concerning  changing 
circumstances  and  response  option  being  developed 

5 .2.2.2 

MoP 

Time  between  response  option  being  developed  and  response  decision 

5.2.3 

MoP 

Time  between  response  decision  and  order  of  response  execution  by  decision- 
authorized  entity 

5.3.2 

MoP 

Median  number  of  connections  between  decision-authorized  entity  and  action- 
authorized  entity 

5.3.4 

MoP 

Percentage  of  entities  connected  by  existing  relationships  and  connections  which  are 
authorized  to  make  a  specific  decision  concerning  a  specific  change  in  circumstances 

5.4.1 

MoP 

Number  of  distinct  response  solutions  generated  by  decision-authorized  entities 
concerning  a  specific  change  in  circumstances 

5.5.2 

MoP 

Percentage  of  action-authorized  entities  with  conflicting  orders  from  decision- 
authorized  entities 

6. 1.3. 3 

MoP 

Percentage  of  action-authorized  entities  which  are  allocated  a  role  or  responsibility 
which  they  cannot  accomplish 

6.2.1 

MoP 

Time  between  order  of  response  execution  by  decision-authorized  entity  and  completion 
of  allocations  by  allocation-authorized  entity 

6.2.2 

MoP 

Time  between  allocation  of  role  or  responsibility  and  commencement  of  role  or 
responsibility  by  action-authorized  entity 

6.3.2 

MoP 

Median  number  of  connections  between  allocation-authorized  entity  and  action- 
authorized  entity 

6.3.4 

MoP 

Percentage  of  entities  connected  by  existing  relationships  and  connections  which  are 
authorized  to  make  allocations  concerning  a  specific  decision 

6.4.2 

MoP 

Percentage  of  roles  and  responsibilities  which  are  required  for  the  specific  decision 
which  are  not  allocated 

Table  6.  Selected  Measures  of  Merit 


E.  REQUIREMENTS 

Requirements  are  developed  with  the  operational  concept,  external  systems 
diagram,  and  the  system  objectives  hierarchy  providing  inputs.  The  following  sections 
discuss  each  type  of  requirement  and  the  applicable  requirements  identified  during  this 
thesis. 


1.  Types  of  Requirements 

Buede  [2000]  organizes  requirements  into  four  groups:  input/output  requirements, 
system-wide  requirements,  trade-off  requirements,  and  qualification  requirements. 
Originating  requirements  are  the  collection  of  these  requirements  which  were  developed 
during  the  operational  concept.  The  following  sections  describe  each  type  of 
requirement. 
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Figure  16.  Requirements  Development  [after  Buede,  2000:  159] 
a.  Input/output  Requirements 

The  external  systems  diagram  is  the  “primary  tool  used  to  support  the 
development  of  input/output  requirements”  [Buede,  2000:  153].  Each  input  and  output 
identified  during  the  development  of  and  included  in  the  external  systems  diagram  must 
have  one  or  more  requirements.  For  example,  a  weapon  system  may  require  an  order 
with  different  characteristics  than  another  weapon  system.  The  differences  between  the 
orders  should  then  be  captured  by  the  output  requirements  of  the  command  and  control 
system.  Rules  and  constraints  for  the  system,  which  can  be  procedural  rules  or  interface 
constraints,  are  included  as  input/output  requirements.  Rules  or  constraints  which  require 
knowledge  of  the  entire  system  to  determine  whether  they  are  met  should  be  included  in 
system-wide  and  technology  requirements.  Federal  regulations  or  laws  pertaining  to  the 
system  are  an  example. 
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b.  System-wide  Requirements 

System-wide  requirements  pertain  “to  the  system  as  a  whole  and  not  to 
specific  inputs  or  outputs”  [Buede,  2000:  154],  This  group  of  requirements  includes 
technology,  suitability,  cost,  and  schedule  requirements.  Technology  requirements  may 
limit  potential  solutions  for  the  system  design,  but  are  usually  included  to  ensure 
interoperability  or  compatibility  with  external  systems  [Buede,  2000:  154].  Suitability 
requirements  address  such  issues  as  usability,  survivability,  availability,  reliability, 
maintainability,  and  testability.  Cost  and  schedule  requirements  are  self-explanatory  and 
are  applicable  to  every  phase  of  the  system’s  life-cycle.  For  the  purposes  of  this  thesis, 
only  technology  and  suitability  requirements  were  considered. 

c.  Trade-off  Requirements 

Trade-off  requirements  are  based  solely  on  the  value  judgments  of 
stakeholders.  Categories  of  trade-off  requirements  can  include  performance  trade-offs, 
cost  trade-offs,  and  cost-performance  trade-offs.  The  techniques  for  elicitation  of  trade¬ 
off  requirements  and  the  set  of  stakeholders  solicited  can  greatly  affect  the  development 
of  trade-off  requirements  and  subsequently  the  system.  As  Buede  [2000:  155]  warns, 
“Care  must  be  taken  to  define  a  sufficiently  large  and  representative  sample  of  these 
users.” 


d.  Qualification  Requirements 

Qualification  requirements  are  developed  to  ensure  the  system  which  is 
built  is  properly  designed  and  is  acceptable.  Qualification  requirements  must  address 
how  the  requirements  are  observed,  verified,  validated,  and  accepted  [Buede,  2000:  155- 
157].  Observation  refers  to  how  the  qualification  data  is  obtained  (e.g.,  testing,  analysis, 
simulation,  inspection,  or  demonstration).  Verification  refers  to  how  it  is  determined  if 
the  built  system  complies  with  the  designed  system.  Validation  refers  to  how  it  is 
determined  built  system  complies  with  the  originating  requirements.  Finally,  acceptance 
refers  to  how  it  is  determined  that  the  built  system  is  acceptable  to  the  stakeholders. 
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2.  Applicable  Requirements 

As  described  in  scenario  development,  and  since  the  focus  of  this  thesis  was  on 
the  architectural  phase  of  the  system  engineering  process,  qualification  and  trade-off 
requirements  were  not  developed.  Only  input/output  requirements  and  system-wide 
requirements  were  considered.  Requirements  generation,  however,  does  not  end  with  the 
conclusion  of  the  operational  concept  development.  Requirements  may,  and  often  times 
will,  become  apparent  throughout  the  remaining  phases  of  the  system  engineering 
process.  Those  input/output  requirements  and  system-wide  requirements  identified 
during  thesis  research  are  shown  in  Table  7.  Given  the  conceptual  nature  of  this  thesis, 
requirements  identified  were  few  and  contained  little  specificity. 


Input/Output  Requirements 

Reference 

All  inputs  to  the  C2  system  are  in  the  form  of  data 

Appendix  E:  Functional 
Decomposition 

All  outputs  from  the  C2  system  must  be  in  the  fonn  of  data 

Appendix  E:  Functional 
Decomposition 

System-wide  Requirements 

Reference 

N/A 

Table  7.  Applicable  Requirements 


F.  CHAPTER  SUMMARY 

The  operational  concept  is  a  general  vision  of  the  system  from  the  view  of  the 
system's  stakeholders  and  is  developed  to  facilitate  the  co-development  of  the  functional 
architecture  and  the  physical  architecture.  Development  of  the  operational  concept  is  not 
complete  until  the  system  engineering  process  is  complete  for  it  is  be  repeatedly  refined 
and  updated  during  the  developments  of  the  functional,  physical,  and  operational 
architectures.  The  operational  concept  describes  the  system  from  an  external  view  by 
defining  boundaries  of  the  system  and  identifying  inputs  to  and  outputs  from  the  system. 
The  purpose  of  the  next  phases  of  the  system  engineering  process,  functional  architecture 
development  and  physical  architecture  development,  is  to  describe  how  the  system 
converts  the  inputs  into  the  desired  outputs  and  to  define  the  means  by  which  it  does  so. 
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V.  FUNCTIONAL  ARCHITECTURE 


A.  INTRODUCTION 

A  function  is  a  process  that  takes  inputs  and  transforms  them  into  outputs  [Buede, 
2000:  178].  Recall  that  a  system  is  “a  set  of  components  (subsystems,  segments)  acting 
together  to  achieve  a  set  of  common  objectives  via  the  accomplishment  of  a  set  of  tasks” 
[Buede,  2000:  38],  A  system,  therefore,  is  defined  by  1)  its  set  of  objectives  and  2)  the 
functions  required  for  it  to  achieve  such  set  of  objectives.  One  purpose  of  the  operational 
concept  is  to  describe  the  objectives  of  the  system.  The  purpose  of  the  functional 
architecture  is  to  describe  what  the  system  is  to  do  with  the  identified  inputs  to  produces 
the  desired  outputs. 

The  first  phase  in  developing  the  functional  architecture,  which  was  conducted  in 
conjunction  with  the  development  of  the  initial  generic  physical  architecture,  was  to 
organize  the  system’s  functions  into  a  hierarchy.  The  next  phase  was  to  detail  the 
relationships  between  the  inputs  and  outputs  of  the  system  (i.e.,  describe  the  sequence  of 
functions  converting  an  input  into  an  output).  The  third  phase  of  the  functional 
architecture  development  was  to  seek  feedback  from  system  stakeholders  concerning  the 
functional  decomposition.  A  primary  purpose  of  the  stakeholder  feedback  is  to  ensure 
there  was  not  an  absence  of  functionality  or  a  redundancy  of  functionality  in  the 
functional  hierarchy.  The  fourth  and  fifth  phases  of  the  functional  architecture 
development,  tracing  of  input/output  requirements  and  incorporation  of  fault  tolerance 
and  security  functions  respectively,  were  not  conducted  during  this  thesis. 

This  chapter  presents  the  key  phases  and  products  derived  within  the  functional 
architecture  development.  Appendix  E:  Functional  Decomposition  and  Appendix  F: 
Input-Output  Relationships  provide  more  details  of  the  functional  architecture 
development  process  outside  those  presented  in  this  section. 

B.  FUNCTIONAL  HIERARCHY 

Developing  a  hierarchy  of  the  system’s  functions  was  the  first  phase  in 

developing  the  functional  architecture  and  was  conducted  in  conjunction  with  the 
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development  of  the  initial  generic  physical  architecture.  To  develop  the  functional 
hierarchy  the  system  engineer  can  use  a  decomposition  approach,  composition  approach, 
or  a  combination  of  both  decomposition  and  composition.  Per  the  recommendation  of 
Buede  [2000:  183]  a  combination  of  both  approaches  was  used  to  develop  the  functional 
hierarchy. 

As  during  the  development  of  the  operational  concept,  a  publication  review  was 
first  conducted  to  provide  the  author  with  foundational  knowledge  of  the  functions  of 
command  and  control.  This  served  as  a  starting  point  for  the  composition  approach.  In 
addition,  comparison  of  the  alternative  C2  functions  served  as  the  first  step  of  the 
stakeholder  feedback  process.  Appendix  E:  Functional  Decomposition  provides  a 
summary  of  the  publication  review.  Work  conducted  during  the  operational  concept 
development  was  reviewed  as  the  next  step  in  developing  a  set  of  system  functions.  First, 
recall  the  refined  problem  statement: 

A  responsive  and  robust  command  and  control  system  which  connects 
dispersed  forces  and  enables  such  forces  to  self-synchronize  and  allocate 
resources  to  mass  effects  in  order  to  meet  the  established  intent  at  the 
tactical  level  of  war. 

Therefore,  three  objectives  of  the  command  and  control  system  are  to  connect  dispersed 
forces,  enable  forces  to  self-synchronize,  and  enable  forces  to  allocate  resources  to  mass 
effects.  Second,  recall  from  the  discussions  concerning  the  external  systems  diagram, 
that  the  inputs  to  and  outputs  from  the  command  and  control  system  are  information. 

During  the  development  of  the  operational  concept,  the  system  is  viewed  as  a 
black  box  [Buede,  2000:  180].  In  other  words,  the  operational  concept  defines  the  inputs 
to  and  outputs  from  the  system  but  does  not  describe  what  the  system  does  to  transform 
the  inputs  into  the  outputs.  It  is  during  the  functional  architecture  development  that  the 
system  engineer  describes  what  the  system  does  and  in  effect  shines  the  light  into  the 
black  box  that  is  the  system  [Buede,  2000:  180].  So,  from  above,  if  a  C2  system  takes 
information  as  inputs  and  gives  information  as  outputs,  then  if  the  C2  system  does 
nothing  else,  it  at  least  moves  information  from  one  portion  of  the  dispersed  force  to 
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another.  In  effect,  it  is  at  least  a  communication  system.  Not  coincidentally, 
communication  system  is  a  subsystem  of  the  C2  system  as  detailed  in  the  external 
systems  diagram. 

Since  communication  system  is  a  subsystem  of  the  C2  system,  the  functions  of 
communications  systems  are  candidates  for  functions  of  a  C2  system.  JP  6-0  [2006:  Ch  I, 
6-8],  presents  eight  functions  of  communication  systems,  as  delineated  in  Appendix  E: 
Functional  Decomposition  -  Acquire  Information,  Process  Information,  Store 
Information,  Transport  Information,  Control  Other  Communications  Functions,  Protect 
Information,  Disseminate  Information,  and  Present  Information.  Dissemination  of 
information  is  simply  the  transport  of  information  from  the  C2  system  to  a  stakeholder  or 
an  external  system.  Acquisition  of  information  is  simply  the  transport  of  information 
from  a  stakeholder  or  an  external  system  to  the  C2  system.  Therefore,  Acquire 
Information  and  Disseminate  Information  are  simply  special  cases  of  Transport 
Information . 

Control  other  communication  functions  is  removed  as  a  function  of  a  C2  system 
for  it  is  implicit  in  the  design  of  a  system.  By  the  mathematical  definition,  which  is  the 
basis  of  Buede’s  [2000]  definition  of  a  function,  a  function  transforms  any  element  of  its 
domain  (i.e.,  particular  input)  to  one  and  only  one  element  of  its  range  (i.e.,  to  one  and 
only  one  particular  output).  Of  course  the  output  from  a  function  may  not  be  the  desired 
output,  but  by  definition  of  a  function  the  output  can  be  known.  This  leads  one  to  the 
topic  of  fault  tolerance.  All  systems  can  have  faults  which  can  cause  errors  which  can 
lead  to  failures  in  the  system.  However,  as  Buede  [2000:  205]  states,  functions  to  detect 
errors  “are  typically  not  part  of  the  initial  drafts  of  the  functional  architecture  because 
they  depend  to  a  significant  degree  on  the  physical  architecture;  as  a  result  these 
functions  are  often  added  once  the  operational  architecture  is  taking  shape.”  This  is  what 
is  meant  by  implicit  in  design,  for  the  systems  engineer  will  have  a  fault  tolerance 
placeholder  in  their  mind  when  defining  system  functions.  Protect  Information  is 
removed  as  a  function  of  a  C2  system  for  similar  argument.  In  essence,  protecting 
information  is  preventing  a  system  failure  of  an  unwanted  entity  obtaining  or  modifying 
information  within  the  C2  system.  In  other  words,  protecting  information  in  a  C2  system 
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is  not  allowing  an  interface  with  an  unwanted  external  system  or  stakeholder.  A  fault  in 
the  system  can  cause  an  error  of  allowing  an  unwanted  interface.  This  can  lead  to  a 
failure  of  the  system  with  an  actual  unwanted  interface.  Security  is  always  an  objective 
of  a  system  where  a  system  is  to  be  used  in  an  environment  with  an  adversary.  Just  as 
with  fault  tolerance  functions,  security  functions  depend  largely  on  the  physical 
architecture  and  should  be  added  once  the  operational  architecture  has  taken  shape.  Four 
functions  of  communication  systems  remain  as  candidates  for  a  C2  system:  Transport 
Information,  Process  Information,  Store  Information,  and  Present  Information. 

Another  function  of  a  C2  system,  as  detailed  in  Appendix  C:  External  Systems 
Diagram,  is  to  connect,  or  link,  the  phases  of  the  C2  process.  A  phase  of  the  C2  process 
can  be  conducted,  partially  or  wholly,  by  external  systems.  For  example,  most  of  the 
conceptual  models  of  the  C2  process  present  a  phase  akin  to  decide.  Given  the  traditional 
military  view  that  a  decision  is  made  by  a  commander  and  that  the  commander  is  viewed 
as  an  external  system  for  this  thesis,  the  phase  of  decision  is  partially  fulfilled  by  an 
external  system.  Since  a  decision  requires  two  options,  even  if  one  option  is  to  do 
nothing,  at  some  time  an  option  must  be  generated.  Of  course  the  option  can  be 
generated  by  the  commander;  however,  this  does  not  enable  forces  to  self  synchronize. 

Recall  that  self-synchronization  is  the  ability  of  a  force  to  “organize  and 
synchronize  complex  warfare  activities  from  the  bottom  up”  [Cebrowski  &  Garstka, 
1998].  At  this  point  in  defining  a  C2  system  it  is  not  obviously  apparent  that  a  C2  system 
needs  to  generate  options.  However,  given  the  increasing  tempo  of  warfare  due  to 
automated  combat  systems  and  faster  weapons,  the  ability  to  generate  options  within  the 
system,  instead  of  aggregating  options  from  external  systems  such  as  the  commander, 
may  become  crucial.  In  fact,  weapon-target  pairing  is  a  form  of  generating  options  that  is 
currently  considered  a  function  of  a  C2  system.  A  C2  system  need  not  be  the  only  entity 
which  generates  options,  but  providing  the  ability  should  be  a  function  of  the  system. 
Following  similar  reasoning,  selecting  an  option,  especially  with  automated  combat 
systems,  should  also  be  a  function  of  a  C2  system.  In  combination,  generating  and 
selecting  options  encompass  allocating  resources.  Generating  options  includes 
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determining  which  available  resources  can  be  used,  while  selecting  options  includes 
determining  what  resources,  if  any,  will  be  used. 

Starting  from  the  refined  problem  statement,  a  C2  system  should  connect 
dispersed  forces,  enable  forces  to  self-synchronize,  and  enable  forces  to  allocate 
resources  to  mass  effects.  To  achieve  these  objectives,  a  C2  system  performs  six 
functions:  Transport  Information,  Process  Information,  Store  Information,  Present 
Information,  Generate  Response  Options,  and  Select  Response  Options.  These  six 
functions  must  be  decomposed  into  a  hierarchy  of  sub-functions  which  then  can  be 
assigned  to  different  resources  identified  in  the  physical  architecture  to  form  the 
operational  architecture. 
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Figure  17.  Top-level  Command  and  Control  System  Functions 

The  following  sections  will  discuss  basic  concepts  helpful  for  the  functional 
decomposition,  discuss  the  functional  decomposition  process,  and  present  the  full 
functional  decomposition  of  the  C2  system.  The  decomposition  of  some  functions 
incorporate  concepts  from  information  theory  and  human  decision  making.  Appendix  E: 
Functional  Decomposition  discusses  the  cognitive  hierarchy  and  certain  conceptual 
models  of  human  decision  making  which  influenced  the  functional  decomposition. 


1.  Transport  Information 

The  first  top-level  function,  transport  information,  is  the  moving  of  information 
from  one  place  to  another.  Recall  that  transport  information  encompasses  dissemination 
of  information  and  acquisition  of  infonnation.  Corresponding  to  the  International 
Standards  Organization  (ISO)  Open  Systems  Interconnection  (OSI)  model,  the  first  level 
of  decomposition  for  transport  information  relates  to  the  transmission  medium. 
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The  second  level  of  decomposition  describes  the  connection  type,  whether  a 
physical  connection  or  remote  connection.  Physical  connection  accounts  for  those 
instances  when  the  infonnation  traverses  through  some  sort  of  guide,  which  physically 
connects  points.  Remote  addresses  those  instances  when  the  connected  points  are  not 
physically  connected  by  a  guide.  A  physical  connection  requires  the  two,  or  more, 
connected  points  to  either  be  stationary  or  move  together.  Remote  allows  the  two,  or 
more,  connected  points  to  move  independent  of  each  other.  Examples  of  physical  and 
remote  connection  methods  for  each  type  of  transmission  medium  are  presented  in  the 
discussion  below  but  are  not  included  in  the  functional  decomposition.  The  specific 
methods  are,  rather,  a  part  of  the  physical  architecture. 

The  first  type  of  transmission  media  considered  is  physical  matter,  which  is 
further  subdivided,  as  described  above,  into  physical  and  remote  connection.  Physical 
matter  transmission  media  are  those  instances  when  the  information  is  stored  in  matter. 
An  example  of  a  physical  connection  using  physical  matter  to  transmit  information  is 
line-pull  signals  for  divers.  In  such  instances  divers  can  communicate  with  persons, 
using  a  predetennined  communication  scheme,  by  tugging  on  a  rope  or  line.  Remote 
connections  using  physical  matter  are  those  instances  when  the  information  is  stored  in 
matter  and  such  matter  is  physically  transported  from  place  to  place.  Per  the  function 
store  information  discussion  below,  the  storage  media  can  be  either  human  or  non¬ 
human.  A  human  messenger,  a  book,  a  compact  disc,  and  a  hard  disk  drive  are  all 
examples  of  physical  matter  storage  which  can  contain  infonnation  and  be  transported. 

The  second  type  of  transmission  media  considered  is  acoustic.  Acoustic  is  further 
subdivided  into  physically  connected  and  remote  systems.  For  example,  a  sound  tube  on 
a  ship  is  a  physically  connected  system  while  shouting  between  ships  is  a  remote  system. 

The  third  type  of  transmission  media  considered  is  electromagnetic  radiation,  and, 

as  above,  is  further  divided  into  physical  connection  and  remote  connection.  Physical 

connection  accounts  for  those  instances  when  the  electromagnetic  radiation  traverses 

through  some  sort  of  guide  which  physically  connects  points.  Examples  of  physical 

connection  include  metal  wires,  wave  guides,  or  fiber-optic  cables.  The  other  methods  of 

electromagnetic  transmission  account  for  those  instances  when  the  connected  points  are 
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not  physically  connected.  These  methods  include  line-of-sight,  ionospheric  reflection, 
tropospheric  scattering,  and  satellite  communications  [Rice  &  Sammes,  1989:  108],  The 
decomposition  of  transport  information  is  presented  in  Figure  18. 


Figure  18.  Functional  Decomposition  -  Transport  Information 

2.  Process  Information 

The  second  top-level  function  is  process  information.  The  means  (i.e.,  resources) 
by  which  the  other  functions  of  the  C2  system  are  executed  often  require  information  in 
different  forms  (i.e.,  different  levels  in  the  cognitive  hierarchy)  or  different  formats  (i.e., 
different  versions  of  the  same  level  in  the  cognitive  hierarchy).  For  example,  storing 
information  may  require  a  different  form  or  format  of  infonnation  than  presenting 
information.  Therefore,  the  first  three  sub-functions  of  process  information  entail 
transfonning  information  into  another  form  or  format. 

Transport  processing  entails  transforming  the  information  into  the  data  form  for 
transport.  It  also  entails  converting  the  data  into  a  format  necessary  for  transport  by  a 
particular  resource  or  set  of  resources.  Similarly,  storage  processing  entails  transforming 
information  into  the  data  form  for  storage  and  converting  the  data  into  a  format  necessary 
for  storage  by  a  particular  storage  resource  or  set  of  resources.  Input  Conversion  and 
Output  Conversion  are  concerned  with  inputs  from  and  outputs  to  external  systems, 
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respectively.  They  entail  converting  the  data  from  the  form  and  format  used  by  the 
external  systems  to  one  useful  by  the  C2  system’s  components,  and  vice  versa. 

Process  information,  however,  includes  three  other  sub-functions.  It  includes 
evaluate  data,  which  is  to  determine  the  accuracy  and  completeness  of  the  data.  Process 
information  also  includes  analyze  information  and  synthesize  information.  Analysis  is 
the  dividing  of  information  into  different  parts.  Synthesis  is  the  combining  of  different 
information  to  produce  new  information.  The  decomposition  of  process  information  is 
presented  in  Figure  19. 


Figure  19.  Functional  Decomposition  -  Process  Information 

3.  Store  Information 

Store  information  is  the  third  top-level  function.  It  is  first  divided,  as  alluded  to  in 
the  discussion  of  physical  transport  of  information,  into  human  storage  and  non-human 
storage.  Human  storage  is  considered  the  biological  composition  of  a  human.  If  a  non¬ 
human  storage  device  is  located  in  a  human  (e.g.,  a  micro-chip  embedded  in  the  skin)  it  is 
considered  non-human  storage.  Non-human  storage  of  information  is  divided  into  short¬ 
term  storage  and  long-term  storage.  Short-term  storage  is  the  storing  of  information  in  a 
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component  external  to  the  processing  component  for  use  only  within  the  operating 
lifetime  of  the  C2  system.  Storing  of  information  within  the  component  processing  the 
information  is  not  considered  a  sub-function  of  store  information,  but  rather  process 
information.  Long-term  storage  is  the  storing  of  information  which  can  be  used  beyond 
the  operating  lifetime  of  the  C2  system. 

Human  storage,  as  in  non-human  storage,  could  be  sub-divided  into  short-term 
and  long-term  storage  however,  it  is  beyond  the  scope  of  this  thesis  to  detennine  and 
describe  the  differences  between  each.  It  is  for  this  reason  that  human  and  non-human 
storage  was  separated  in  the  functional  architecture,  even  though  such  separation  is 
similar  to  divisions  made  in  the  physical  architecture.  The  decomposition  of  store 
information  is  presented  in  Figure  20. 


Figure  20.  Functional  Decomposition  -  Store  Information 

4.  Present  Information 

The  fourth  top-level  function  is  present  information.  As  discussed  previously, 
dissemination  of  information  is  the  transport  of  information  from  the  C2  system  to  a 
stakeholder  or  an  external  system.  Present  information  is  portraying  information  to  those 
stakeholders,  external  systems,  or  subsystems  which  are  comprised  of  humans.  In  many 
cases  when  information  is  transported  to  an  external  system  or  stakeholder,  the 
information  needs  to  be  processed  into  a  fonn  useful  to  such  external  system  or 
stakeholder.  Human  systems,  however,  differ  from  non-human  systems  in  their  ability  to 
use  cognition.  Cognition  uses  more  than  the  processed  information  to  create  knowledge 
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and  understanding  for  the  human.  Human  cognition,  as  Boyd  discusses  in  his 
Orientation  phase  of  the  OODA  loop,  also  uses  genetic  heritage  and  cultural  traditions  as 
inputs.  These  inputs  to  a  human  stakeholder,  external  system,  or  subsystem  are  beyond 
the  purview  of  the  C2  system.  Of  course  non-human  external  systems  may  have  inputs 
beyond  the  purview  of  the  C2  system,  but  such  systems  can  be  designed  to  account  for 
such  inputs.  However,  in  the  cases  of  genetic  heritage  and  cultural  traditions,  humans 
cannot  be  designed  without  considerable  ethical  considerations.  The  notion  of  past 
experiences,  from  Boyd’s  Orientation  phase,  was  not  included  since  training  is  a  means 
of  establishing  a  base  for  past  experiences  and  thus,  in  effect,  designing  the  human 
system. 

Present  information  entails  portraying  infonnation  to  human  stakeholders, 
external  systems,  or  subsystem  for  cognition.  The  next  level  of  decomposition  for 
present  information  follows  the  methods  of  input  to  a  human.  A  human,  when  viewed  as 
a  system,  can  absorb  inputs  from  an  external  system  in  six  ways.  The  first  five  forms  of 
inputs  follow  the  five  traditionally  accepted  forms  of  human  senses.  The  sense  of  motion 
and  pressure  are  included  with  the  sense  of  touch.  The  sixth  form  of  input  to  a  human  is 
direct  connection  with  the  brain  and  nervous  system.  For  ethical  reasons,  the  sixth  form 
of  input  was  not  considered  as  a  feasible  function  for  the  C2  system.  Additionally, 
olfactory  and  gustatory  inputs  were  not  decomposed.  Present  information,  therefore,  is 
decomposed  into  visual  presentation,  aural  presentation,  physical  presentation,  olfactory 
presentation,  and  gustatory  presentation  .  Some  of  these  sub-functions  were  further 
decomposed  by  their  respective  methods.  Visual  presentation  can  be  in  the  form  of  text, 
symbols,  or  pictures.  The  time  varying  nature  is  an  attribute  of  these  functions. 
Therefore,  video  is  considered  a  picture  which  varies  with  time.  Aural  presentation 
consists  of  voice  and  sounds.  Physical  presentation  can  be  in  the  form  of  touch  or 
motion.  Finally,  olfactory  presentation  and  gustatory  presentation  were  not  decomposed 
because  they  were  presumed  to  only  have  one  method  each  for  presentation.  The 
decomposition  of  present  information  is  presented  in  Figure  2 1 . 
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Figure  2 1 .  Functional  Decomposition  -  Present  Information 

Present  information  is  concerned  with  output  of  the  C2  system  at  the  human- 
system  interface.  The  input  to  the  C2  system  at  the  human-system  interface  was  not 
neglected  in  the  top-level  functions;  it  was  accounted  for  in  process  information  .  Of 
course  humans  may  be  better  able  to  portray  certain  cognitive  infonnation  using  certain 
methods  (e.g.,  it  may  be  easier  to  “speak  your  mind”  than  to  “draw  your  mind”). 
However,  engineers  have  designed  many  standard  input  interface  systems  (e.g., 
keyboards,  joysticks,  levers,  buttons,  and  microphones)  and  humans  have  been  trained  to 
convey  their  cognitive  information  via  these  interface  systems.  A  top-level  function 
addressing  the  inputs  from  humans  could  have  easily  been  included  similarly  to  present 
information.  However,  the  notion  of  standard  input  interfaces  and  the  human  system 
processing  the  information  into  a  fonn  which  the  C2  system  can  process  led  the  author  to 
view  the  input  at  the  human-system  interface  as  part  of  process  information. 
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5.  Generate  Response  Options 

Generate  response  options  is  the  fifth  top-level  function.  To  better  understand 
generate  response  options  and  its  sub-functions,  tenninology  should  be  reviewed.  First, 
intent,  whether  it  is  an  input  to  the  C2  system  by  the  commander  or  is  established  by  the 
C2  system,  is  comprised  of  a  purpose  and  an  objective.  A  mission  is  an  assignment  to  a 
force  with  a  purpose,  detennined  by  the  intent,  and  consists  of  a  set  of  tasks.  “The 
mission  establishes  the  requirement  to  perform  tasks  and  provides  the  context  for  each 
task  performance”  [CJCSM  3500. 04D,  2005:  Enclosure  A,  7].  A  task  is  an  action  or 
activity  assigned  to  a  resource  and  is  detennined  by  analysis  of  the  mission,  doctrine, 
and/or  standard  operating  procedures.  Finally,  a  response  option  is  a  set  of  tasks,  with 
associated  resources,  which  is  a  solution  to  achieve  the  mission  objective  given  the 
changing  circumstances. 

First,  to  generate  response  options  the  C2  system  must  determine  changing 
circumstances.  This  sub-function  is  further  divided  into  detecting,  identifying, 
classifying,  and  confirming  the  changing  circumstances.  Detecting  is  discovering 
differences  between  current  and  past  or  expected  circumstances.  Identifying  is 
recognizing  the  detected  changing  circumstances  as  a  specific  type.  Classifying  is 
categorizing  the  detected  changing  circumstances  by  level  of  danger  they  present. 
Confirming  is  verifying  the  identification  and  classification  of  the  detected  changing 
circumstances. 

Second,  the  C2  system  must  determine  the  required  tasks.  In  the  cases  where  the 
intent  or  mission  is  an  input  to  the  C2  system  certain  tasks  are  specified  and  certain  tasks 
are  implied.  Therefore,  two  sub-functions  of  determine  required  tasks  are  to  identify  the 
specified  tasks  and  hypothesize  implied  tasks.  When  the  intent  is  established  within  the 
C2  system,  there  is  possibly  no  explicit  intent  or  mission.  Therefore,  tasks  emerge  as  a 
result  of  the  changing  circumstances.  The  C2  system  must  then  hypothesize  emergent 
tasks.  Additionally,  when  refining  response  options,  the  C2  system  must  also  confirm 
required  tasks. 
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Third,  since  a  task  is  an  action  or  activity  assigned  to  a  resource,  the  C2  system 
must  identify  resources  for  required  tasks.  Finally,  allocate  resources  for  required  tasks 
is  another  sub-function.  The  decomposition  of  generate  response  options  is  presented  in 
Figure  22. 


Figure  22.  Functional  Decomposition  -  Generate  Response  Options 

6.  Select  Response  Options 

The  sixth  and  final  top-level  function  is  select  response  options,  which  is 
comprised  of  three  sub-functions.  First,  the  C2  system  should  be  capable  of  evaluating 
response  options  generated.  At  a  minimum,  the  C2  system  should  evaluate  feasibility, 
evaluate  completeness,  evaluate  legality,  and  estimate  effectiveness.  Feasibility  addresses 
whether  the  resources  allocated  tasks  are  capable  of  accomplishing  the  task. 

Completeness  addresses  whether  all  of  the  required  tasks  of  the  response  option  are 
allocated  to  resources.  Legality  addresses  whether  the  required  tasks  are  legal  or  the 
resources  allocated  to  a  task  can  legally  execute  the  task.  Note  a  response  option  need 
not  be  feasible,  complete,  or  effective  to  be  selected.  A  response  option  in  which  all 
tasks  are  assigned  to  resources  but  with  at  least  one  task  assigned  to  a  resource  incapable 

of  accomplishing  it  is  deemed  infeasible;  it  can  also  be  deemed  incomplete  if  such  task  is 
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viewed  as  unassigned.  In  either  view  of  such  response  options,  it  is  conceivable  that  a  C2 
system  may,  in  some  cases,  select  an  infeasible  or  incomplete  response  option. 
Effectiveness  is  detennined  through  hypothesizing  expected  circumstances  and 
estimating  the  expected  effects  of  a  response  option.  Therefore,  an  infeasible  or 
incomplete  response  option  is  likely  to  be  ineffective,  but  it  is  also  possible  for  feasible 
and  complete  responses  to  be  so  as  well.  Not  allowing  a  C2  system  to  select  an 
ineffective  response  option  may  result  in  a  situation  where  no  response  options  are 
available,  which  may  be  worse  than  having  poor  response  options  to  choose  from.  In 
addition,  it  is  assumed  that  a  response  option  evaluated  to  be  illegal  would  not  be 
selected. 

Second,  a  C2  system,  when  containing  human  components  with  decision-making 
authority,  should  judge  response  options.  The  purpose  of  this  function  is  to  determine  the 
morality  of  a  specific  response  option.  Finally,  to  complete  the  response  selection  the  C2 
system  must  assign  tasks  to  resources.  The  decomposition  of  select  response  options  is 
presented  in  Figure  23. 


Figure  23.  Functional  Decomposition  -  Select  Response  Options 

C.  FULL  FUNCTIONAL  DECOMPOSITION 

All  functions  and  sub-functions  discussed  in  this  thesis  are  collected  and 
presented  below  in  Table  8.  Functions  which  were  identified  as  possible  for  the  C2 


60 


system  but  were  deemed  infeasible  or  beyond  the  bounds  of  this  thesis  are  listed  with 
strike-through  font.  Additionally,  the  top-levels  of  the  functional  decomposition  are 
presented  in  diagram  form  in  Figure  24.  Further  discussion  of  the  functional 
decomposition  is  presented  in  Appendix  E:  Functional  Decomposition.  Fault- tolerance 
and  security  functions  are  not  included  below  since  they  are  not  identified  until  the 
development  of  the  operational  architecture  begins  to  take  shape.  As  discussed 
previously,  comparison  of  the  alternative  C2  functions  served  as  the  first  step  of  the 
stakeholder  feedback  process.  In  addition,  feedback  was  solicited  from  C2  researchers 
and  military  officers  via  an  online  discussion  board  and  personal  correspondence. 

1.0  Transport  information 

1.1.  Physical  matter 

1.1.1.  Physical  connection 

1.1.2.  Remote  connection 

1.2.  Acoustic  waves 

1.2.1.  Physical  connection 

1.2.2.  Remote  connection 

1.3.  Electromagnetic 

1.3.1.  Physical  connection 

1.3.2.  Remote  connection 
2.0  Process  information 

2.1.  Convert  Data 

2.1.1.  Transport  conversion 

2.1.2.  Storage  conversion 

2.1.3.  Input  conversion 

2.1.4.  Output  conversion 

2.2.  Evaluate  data 

2.2.1.  Evaluate  accuracy  of  data 

2.2.2.  Evaluate  completeness  of  data 

2.3.  Analyze  information 

2.4.  Synthesize  information 
3.0  Store  information 

3.1.  Human 

3.2.  Non-human 

3.2.1.  Short-term  Storage 

3.2.2.  Long-term  Storage 
4.0  Present  information 

4.1.  Visual 

4.1.1.  Text 

4.1.2.  Symbols 

4.1.3.  Pictures 

4.2.  Aural 
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4.2.1.  Voice 

4.2.2.  Sounds 

4.3.  Physical 

4.3.1.  Touch 

4.3.2.  Motion 

4.4.  Olfactory 

4.5.  Gustatory 

4.6.  Direct 

5.0  Generate  response  options 

5.1.  Detennine  changing  circumstances 

5.1.1.  Detect  changing  circumstances 

5. 1 . 1 . 1 .  Detect  differences  between  present  and  past  circumstances 

5. 1.1. 2.  Detect  differences  between  present  and  expected  circumstances 

5.1.2.  Identify  changing  circumstances 

5.1.3.  Classify  changing  circumstances 

5.1.4.  Confirm  changing  circumstances 

5.2.  Detennine  required  tasks 

5.2.1.  Identify  specified  tasks 

5.2.2.  Hypothesize  implicit  tasks 

5.2.3.  Hypothesize  emergent  tasks 

5.2.4.  Confirm  required  tasks 

5.3.  Identify  resources  for  required  tasks 

5.4.  Allocate  resources  for  required  tasks 
6.0  Select  response  options 

6.1.  Evaluate  response  options 

6.1.1.  Evaluate  feasibility  of  options 

6.1.2.  Evaluate  completeness  of  options 

6.1.3.  Evaluate  legality  of  options 

6. 1.3.1.  Compare  assigned  tasks  with  law  of  armed  conflict 

6. 1.3.2.  Compare  assigned  tasks  with  rules  of  engagement 

6.1.4.  Estimate  effectiveness  of  option 

6. 1.4.1.  Hypothesize  expected  circumstances 

6. 1.4.2.  Estimate  measures  of  effectiveness 

6.2.  Judge  response  options 

6.3.  Assign  tasks  to  resources _ 

Table  8.  Functional  Decomposition 
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Figure  24.  Functional  Decomposition  -  Top  Three  Levels 
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D.  INPUT/OUTPUT  RELATIONSHIPS 


After  the  functional  hierarchy  was  detailed  sufficiently,  two  to  four  levels  as 
suggested  by  Buede  [2000:  204],  the  next  phase  of  the  functional  architecture 
development  was  to  describe  the  relationships  between  inputs  and  outputs  of  the  system. 
During  the  operational  concept,  interaction  diagrams  were  developed  demonstrating  the 
relationship  between  certain  inputs,  outputs,  and  the  system.  These  relationships  were 
further  detailed  to  explain  the  process  (i.e.,  sequence  of  functions)  by  which  the  inputs 
become  the  outputs.  In  other  words,  the  purpose  of  this  phase  was  to  describe  or  model 
the  sequence  of  functions  which  convert  inputs  into  outputs. 

There  are  multiple  methods  which  the  system  engineer  can  utilize  to  detail  these 
relationships  including  functional  flow  block  diagrams,  data  flow  diagrams,  N2  charts,  or 
IEDF0  diagrams.  IDEFO  diagrams  were  chosen  to  remain  consistent  with  the  work  in  the 
operational  concept.  Figure  25.  presents  the  A-0  diagram,  the  highest  level  of  the  C2 
system  relationship  diagrams;  a  black-box  visualization  of  the  system.  It  is  akin  to  the 
external  systems  diagram  and  the  basic  external  systems  diagram  developed  in  the 
operational  concept.  The  primary  difference,  however,  is  the  A-0  IDEFO  diagram  does 
not  specify  the  external  systems  from  which  inputs  are  received  and  to  which  outputs  are 
sent.  Figure  25.  also  shows  that  the  AO  diagram  presented  in  Figure  26.  that  is  a  sub¬ 
diagram  of  the  A-0.  The  AO  diagram  in  Figure  26.  presents  the  interactions  of  the 
system’s  top  level  functions.  The  AO  diagram  is  the  apex  of  the  collection  of  relationship 
diagrams  which  shine  light  into  the  black-box  system.  The  mechanisms  shown  in  both 
diagrams  were  determined  during  the  development  of  the  physical  architecture,  which  is 
discussed  in  Chapter  VI.  The  remaining  collection  of  developed  relationship  diagrams  is 
presented  in  Appendix  F:  Input-Output  Relationships. 

The  color  selection  of  lines  and  font  in  the  relationship  diagrams  is  not  standard 
for  IDEFO,  but  were  implemented  for  readability.  Red  lines  and  red,  italic,  sans-serif 
fonts  denote  procedures  and  controls,  which  will  be  discussed  in  the  physical 
architecture.  Blue  lines  and  blue,  bold,  serif  fonts  denote  mechanisms,  again  which  will 
be  discussed  in  the  physical  architecture.  Black  lines  and  black,  sans  serif  fonts  denote 
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inputs  and  outputs.  In  those  instances  where  an  output  of  one  function  was  a  control  for 
another  function,  the  line  and  font  was  drawn  in  red. 


Figure  25.  Relationship  Diagram  -  A-0 
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Figure  26.  Relationship  Diagram  -  AO 

The  AO  diagram  in  Figure  26.  presents  the  interactions  of  the  system’s  top  level 
functions.  The  diagram  demonstrates  the  internal  process  to  take  inputs  to  produce 
desired  outputs.  First,  the  C2  system  accepts  inputs  from  external  sensor  systems, 
weapon  systems,  platforms,  and  people  (e.g.,  established  intent).  The  C2  system  then 
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processes  the  inputs  for  transport,  storage,  or  presentation.  The  transported  and  stored 
information  are  then  processed  to  produce  information  on  current  and  past  circumstances. 
The  system  then  takes  current  and  past  circumstances  along  with  established  intent,  when 
it  is  available,  to  produce  a  response  option.  The  response  option  is  then  processed, 
transported,  and/or  stored.  If  the  response  option  is  selected,  it  becomes  a  response  that  is 
processed,  transported,  and/or  stored  once  again.  From  the  response,  an  executable 
response  is  created  that  is  processed,  transported,  and/or  stored  to  finally  produce  an 
assignment  and/or  warning  to  external  systems  and  people.  If  the  response  option  was 
not  selected,  it  would  be  processed,  transported,  and/or  stored  and  used  as  input  to 
generate  a  new  response  option. 

One  key  idea  demonstrated  in  the  diagram  is  the  centrality  of  the  function  Process 
Information.  It  is  the  first  function  of  the  C2  system  for  all  inputs.  In  addition,  it 
provides  input  to  all  of  the  other  top-level  functions.  By  no  means  is  Process  Information 
the  only  critical  function.  All  of  the  top-level  functions  are  critical  functions  of  the 
system.  Rather,  the  systems  engineer  should  realize  in  developing  the  physical 
architecture,  that  the  procedures  for  and  controls  on  Process  Information  will  have 
substantial  impact  on  all  of  the  sub-functions  and  the  C2  system  as  a  whole. 

E.  INPUT/OUTPUT  REQUIREMENTS  TRACE,  FAULT  TOLERANCE 

FUNCTIONS,  AND  SECURITY  FUNCTIONS 

The  final  two  phases  of  the  functional  architecture  development  are  the  trace  of 
input/output  requirements  and  the  inclusion  of  fault  tolerance  and  security  functions. 
Given,  as  discussed  in  Chapter  IV,  the  limited  number  and  general  requirements 
identified,  a  trace  of  input/output  requirements  was  not  formally  conducted. 

Additionally,  as  Buede  [2000:  205]  discusses,  fault  tolerance  and  security  functions 
depend  significantly  on  the  physical  architecture  and  are  not  typically  included  in  the 
functional  architecture  until  the  operational  architecture  takes  form.  Given  the  scope  of 
this  thesis  and  the  conceptual  nature  of  the  physical  and  operational  architectures, 
identification  and  development  of  fault  tolerance  and  security  functions  were  not 
conducted. 
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F.  CHAPTER  SUMMARY 

The  purpose  of  the  functional  architecture  was  to  describe  what  the  system  was  to 
do  with  the  identified  inputs  to  produces  the  desired  outputs.  Key  phases  of  the 
functional  architecture  development  were  conducted  simultaneously  with  the 
development  of  the  physical  architecture,  as  presented  in  the  following  chapter.  First,  the 
functions  of  the  proposed  C2  system  were  identified  and  organized  into  a  hierarchy. 
Second  the  relationships  between  inputs  and  outputs  of  the  system  were  detailed  through 
relationship  diagrams.  In  addition,  informal  stakeholder  feedback  was  conducted  through 
a  survey  of  C2  functions  and  solicitation  from  C2  researchers  and  military  officers  via  an 
online  discussion  board  and  personal  correspondence.  The  following  chapter  presents  the 
physical  architecture  development  process  conducted  simultaneously  with  the  functional 
architecture.  The  products  of  the  physical  architecture  along  with  those  of  the  operational 
concept  and  functional  architecture  are  incorporated  in  the  operational  architecture. 
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VI.  PHYSICAL  ARCHITECTURE 


A.  INTRODUCTION 

The  purpose  of  the  physical  architecture  is  to  describe  the  resources  that  comprise 
the  system,  with  resources  for  every  function  identified  during  the  development  of  the 
functional  architecture  [Buede,  2000:  215-216].  In  addition,  the  physical  architecture 
also  describes  the  procedures  by  which  the  system  is  used  [Buede,  2000:  218], 

Physical  architectures  are  either  generic  or  instantiated.  A  generic  physical 
architecture  is  developed  in  parallel  with  the  functional  architecture  [Buede,  2000:  221] 
and  partitions  the  resources  into  common  categories  without  performance  characteristics 
for  the  resources.  The  generic  physical  architecture  also  identifies  procedures  and 
controls  affecting  the  system  without  specified  attributes.  An  instantiated  physical 
architecture  is  a  generic  physical  architecture  with  performance  characteristics  or 
specified  attributes  of  the  system  resources,  procedures,  and  controls.  This  chapter 
presents  the  key  phases  and  products  within  the  physical  architecture  development. 

B.  GENERIC  PHYSICAL  ARCHITECTURE  COMPONENTS 

The  first  step  of  the  physical  architecture  development  is  to  identify  the  generic 
subsystems,  components,  and  configuration  items.  A  subsystem  is  a  set  of  components 
which  is  less  than  the  system  itself.  A  component  is  a  subset  of  physical  resources  of  the 
system  to  which  a  subset  of  the  system’s  functions  have  been  allocated  [after  Buede, 
2000:  Glossary].  A  configuration  item  is  the  lowest  level  of  components.  As  an 
example  of  these  levels  of  components,  recall  the  two  subsystem  categories  identified 
during  the  external  systems  diagram  development  -  people  and  communication  and 
information  systems.  One  of  the  identified  people  subsystems  was  staff.  Components  of 
a  commander’s  staff  can  be  operations,  logistics,  and  legal  staffs.  The  configuration 
items,  in  this  case,  are  the  individuals  which  comprise  the  various  levels  of  staffs.  In  fact, 
decomposing  and  reorganizing  the  two  subsystem  categories  serves  as  an  opportune 
starting  point  for  describing  the  generic  physical  architecture. 
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1.  People 

The  people  subsystem  category  is  comprised  of  three  generic  components,  namely 
commanders  (subordinate),  staff,  and  personnel.  All  three  types  of  the  people 
components  are  subordinate  to  a  commander,  when  one  is  designated.  Recall  that 
command  is  comprised  of  both  the  authority  over  subordinates  and  the  responsibility  for 
subordinates.  Also  recall  that  authority  can  be  delegated.  Differences  between  each  of 
the  three  people  components  are  primarily  authority  and  responsibility. 

a.  Commanders  (Subordinate) 

When  there  is  no  specific  entity  designated  responsible  for  the 
accomplishment  of  a  mission,  the  commanders  of  the  forces  involved  in  the  mission  fall 
within  the  C2  system.  When  there  is  a  specific  entity  designated  responsible  for  the 
accomplishment  of  a  mission,  such  senior  commander  falls  outside  the  C2  system  while 
subordinate  commanders  fall  within  the  system.  Subordinate  commanders  are 
responsible  for  and  have  authority  over  a  portion  of  a  senior  commander’s  forces 

b-  Staff 

As  discussed  previously,  the  staff  subsystem  can  be  comprised  of  several 
component  staffs.  Traditional  staff  divisions  have  been  between  administrative, 
intelligence,  operations,  logistics,  plans,  communications,  and  training  [Mack,  1998:  172- 
176].  Given  the  purpose  of  the  staff  is  to  support  the  commander,  staff  organization  is 
often  tailored  to  meet  the  commander’s  needs  or  desires.  In  some  cases  commanders 
have  joined  traditionally  separate  component  staffs  just  as  operations  and  plans.  These 
component  staffs,  in  some  cases,  are  further  divided.  In  all  cases,  the  configurable  item 
for  the  staff  is  the  individual  person. 

c.  Personnel 

Personnel  are  those  persons  who  are  assigned  to  a  commander  who  are  not 
subordinate  commanders  or  staff.  Specifically,  personnel  do  not  have  authority  over  or 
responsibility  for  a  portion  of  a  commander’s  forces.  A  personal  aide,  a  person  standing 
watch,  and  a  contractor  are  examples  of  personnel. 
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Figure  27.  People  Components 

2.  Communications  and  Information  Systems 

The  second  subsystem  category,  communications  and  information  systems, 
consists  of  numerous  generic  components.  Rice  and  Sammes  [1989]  present  the  basic 
components  of  a  communications  and  information  system.  First,  an  information 
processing  system  requires  an  input  component,  an  output  component,  a  processor,  and  a 
memory  component  (sub-divided,  potentially,  into  short-term  and  long-term  storage) 
[Rice  &  Sammes,  1998:  37].  The  information  processing  system  is  then  connected  by  a 
communications  system.  The  communications  system  can  also  connect  other  subsystems 
of  the  C2  system,  namely  people.  In  fact,  the  decomposition  of  a  C2  system  by  Rice  and 
Sammes  is  consistent  with  this  thesis  and  doctrinal  concepts  presented  in  Chapter  II.  A 
C2  system,  they  state,  “describes  the  combination  of  information  systems  (including 
communications  systems),  procedures  and  personnel  used  to  effect  the  command  and 
control  process”  [1989:  4].  Therefore,  the  major  components  of  the  communications  and 
information  subsystem  are  input  interfaces,  output  interfaces,  processors, 
memory/storage,  and  links. 

a.  Input  Interface  and  Output  Interface 

The  first  two  types  of  components  of  an  information  system  are  input  and 
output  interfaces.  An  interface  is  a  resource  for  connecting  two  or  more  distinct  systems 
or  subsystems.  The  connection  can  be  between  the  system,  or  subsystems,  and  external 
systems  (external  interface)  or  between  subsystems  (internal  interface).  When  an 
interface  is  for  accepting  an  input  from  an  external  system  to  the  C2  system  or  subsystem, 
it  is  deemed  an  input  interface.  Conversely,  when  the  function  of  the  interface  is  for 
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disseminating  an  output  to  an  external  system  from  the  C2  system  or  subsystem  it  is 
deemed  an  output  interface.  In  the  case  of  an  internal  interface,  the  interface  can  be 
designed  to  serve  as  both  an  input  interface  for  one  subsystem  and  an  output  interface  of 
another  subsystem.  Input  and  output  interfaces  can  be  common  electronic  systems  such 
as  keyboards  and  video  displays  but  can  also  be  human  actions  such  as  spoken  word. 

b.  Processor 

The  third  type  of  component  of  an  information  system  is  processor.  The 
purpose  of  the  processor  is  either  to  transfonn  information  or  convert  data.  First,  through 
a  combination  of  evaluation,  synthesis,  and  analysis,  a  processor  can  transform  data  to 
information  or  information  to  data.  Second,  a  processor  can  convert  data  from  one 
format  to  another  format.  A  human  can  serve  as  a  processor  for  both  transformation  and 
data  conversion,  as  well.  Transforming  information  to  or  from  knowledge, 
understanding,  or  wisdom  requires  a  combination  of  functions,  in  particular  processing 
and  storing,  and  is  therefore  beyond  the  capabilities  of  a  processor.  Though  a  human  can 
serve  as  a  processor,  when  they  transform  information  to  or  from  knowledge, 
understanding,  or  wisdom  they  are  not  deemed  a  processor  for  purposes  of  this  thesis. 

The  distinctions  between  different  forms  of  information  is  discussed  in  Appendix  E: 
Functional  Decomposition 

c.  Memory/Storage 

Memory  or  storage  is  the  fourth  type  of  component  of  an  information 
system.  For  the  purpose  of  this  thesis,  memory  is  a  component  for  storing  information 
within  the  operating  lifetime  of  the  C2  system  while  storage  is  a  component  for  storing 
information  beyond  the  operating  lifetime  of  the  C2  system.  As  highlighted  in  the 
functional  architecture,  individual  humans  can  be  considered  as  memory  and  storage. 

d.  Link 

Links  are  the  final  type  of  component  for  communication  and  information 
systems.  A  link  connects  the  output  interface  of  a  subsystem  with  the  input  interface  of 
another  subsystem.  The  link  can  either  be  a  physical  connection  via  a  designed  system  or 


72 


a  remote  connection.  Remote  connections  allow  the  connected  entities  to  be 
independently  mobile  while  physical  connections  require  the  connected  entities  to  move 
with  each  other. 

As  alluded  to  in  the  functional  architecture,  links  can  also  be  described  by 
the  method  in  which  the  information  is  transported.  The  information  can  be  stored  in 
physical  matter  such  as  a  compact  disk  or  human  and  transported  between  two 
geographically  separate  nodes.  Additionally,  the  information  can  be  transmitted  through 
a  medium,  whether  through  a  physical  connection  such  as  a  waveguide  or  a  remote 
connection  such  as  acoustic  waves.  Links  can  differ  in  geographical  size  from  a  fraction 
of  an  inch  on  a  circuit  board  to  thousands  of  miles  in  the  case  of  satellite 
c  ommunications . 
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Figure  28.  Communication  and  Information  System  Components 

C.  PHYSICAL  ARCHITECTURE  PROCEDURES  AND  CONTROLS 


In  addition  to  describing  the  physical  resources  which  comprise  the  system,  the 
physical  architecture  also  describes  the  procedures  by  which  the  system  is  used  [Buede, 
2000:  218].  Similar  to  the  physical  components,  procedures  and  controls  also  have 
attributes  which  affect  the  performance  of  the  system  and  can  have  multiple 
instantiations.  During  the  development  of  the  physical  architecture,  at  least  six 
procedures  and  controls  of  the  C2  system  were  identified  with  multiple  instantiations. 
These  generic  procedures  and  controls  include  ethics,  rules  of  engagement,  weapons 
control  status,  and  tactics,  techniques,  and  procedures  (TTPs)  for  C2. 

Ethics  are  a  set  of  moral  principles  or  a  system  of  moral  values  [Misch,  1994: 
398].  For  the  purpose  of  this  thesis,  ethics  are  the  basis  by  which  the  morality  of  an 
option  or  decision  is  judged.  Rules  of  engagement  are  procedures  and  controls  which 
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specify  how  and  to  what  limit  forces  will  initiate  or  continue  combat  engagement  with 
other  forces.  Weapons  control  status  denotes  how  and  on  which  classification  of  targets 
weapons  systems  can  be  used.  For  purposes  of  this  thesis,  C2  TTPs  were  decomposed 
into  three  primary  categories  -  situational  awareness,  decision  authority,  and  allocation 
authority.  Situational  awareness  is  a  category  to  group  TTPs  and  controls  that  affect  the 
sharing  and  dissemination  of  situational  information  within  the  networked  force. 

Decision  authority  is  a  category  to  group  TTPs  and  controls  that  affect  the  decisions 
within  the  networked  force,  which  are  applicable  to  the  changing  circumstances  of  the 
situation.  Allocation  authority  is  a  category  to  group  applicable  TTPs  and  controls  that 
affect  the  allocation  of  roles  and  responsibilities  of  the  networked  force. 

D.  INSTANTIATED  PHYSICAL  ARCHITECTURE 

Once  the  generic  components,  procedures,  and  controls  of  the  physical 
architecture  were  identified,  the  next  step  was  to  specify  attributes  and  perfonnance 
characteristics  for  each,  from  which  alternative  instantiated  physical  architectures  could 
be  designed  and  selected.  There  are  many  techniques  for  generating  numerous  physical 
architecture  alternatives.  The  morphological  box  technique,  suggested  by  Buede  [2000: 
222-226],  was  used  for  developing  the  physical  architecture  alternatives.  “In  the  two- 
dimensional  version  a  table  is  created  with  columns  (or  sometimes  the  rows)  pertaining  to 
the  generic  components  of  the  physical  architecture.  Then  the  elements  of  each  column 
are  filled  with  competing  specific  instantiations  of  each  component”  [Buede,  2000:  223]. 

As  in  the  functional  architecture,  there  are  varying  levels  within  the 
morphological  box.  From  the  top-level  morphological  box  to  lower  level  boxes,  the 
systems  engineer  describes  alternative  physical  components  with  greater  and  greater 
detail.  Taking  the  wrist  watch  example  of  a  system,  a  generic  component  of  the  system 
would  be  a  time  presenter.  The  highest  level  of  the  morphological  box  for  such 
component  could  list  visual  display  and  audio  presentation  as  two  alternatives.  The  next 
lower  level  for  visual  display  could  list  analog  display,  digital  display,  and  combination 
display.  The  next  lower  level  for  digital  display  could  list  12-hour  notation  and  24-hour 
notation.  This  decomposition  can  be  continued  as  is  pertinent  to  the  system  under  design. 
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The  following  sections  present  the  top-level  morphological  boxes  developed  and  discuss 
the  instantiations  of  the  components,  procedures,  and  controls. 

1.  Physical  Architecture  Components 

The  top  level  morphological  box  for  the  physical  components  is  presented  in 
Table  9.  This  is  by  no  means  an  exhaustive  list  of  alternatives.  Rather,  this  box  served  as 
a  tool  by  which  alternative  physical  architectures  could  be  generated.  The  first  row 
presents  the  generic  components  with  the  remaining  entries  in  each  column  denoting  the 
specific  instantiations.  Details  concerning  each  of  the  alternatives  for  the  generic 
physical  components  of  the  physical  architecture  are  presented  in  the  discussions  below. 
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a.  Commanders  (Subordinate) 

Subordinate  commanders  are  responsible  for  and  have  authority  over  a 
portion  of  a  force.  Commanders,  whether  subordinate  or  not,  can  be  delineated  in  at  least 
three  possible  ways.  First,  commanders’  responsibilities  can  be  divided  functionally.  For 
example,  one  commander  can  be  responsible  for  airspace,  while  another  is  responsible  for 
the  subsurface  of  the  ocean,  while  another  is  responsible  for  amphibious  operations. 
Second,  commanders’  responsibilities  can  be  divided  geographically,  that  is  each 
commander  is  responsible  for  everything  which  occurs  within  a  geographic  region. 

Third,  commanders’  responsibilities  can  be  divided  by  the  resources  which  they 
command.  For  example,  in  a  joint  operation  a  commander  can  be  responsible  for  all  of 
the  service  component  forces,  or  in  a  multi-national  operation  a  commander  can  be 
responsible  for  all  of  his  or  hers  nation’s  forces,  despite  the  functional  capability  or 
geographic  location  of  the  forces.  Fourth  and  fifth,  commanders’  responsibilities  can  be 
divided  through  a  combination  of  functional  and  resource  or  functional  and  geographic. 

b.  Staff 

Staff  may  have  authority  over  a  portion  of  a  senior  commander’s  forces 
but  do  not  have  responsibility  for  such  portion  of  forces.  Staffs  can  be  organized 
according  to  at  least  three  major  methods.  First,  a  staff  can  be  organized  functionally.  In 
this  method  staffs  are  organized  according  to  services  which  they  provide,  such  as 
intelligence,  logistics,  and  personnel.  This  is  a  traditionally  accepted  method  for  staff 
organization,  having  been  used  extensively  by  the  Prussian  military  [Hurley,  2005:  91- 
96].  Second,  a  staff  can  be  organized  by  project  or  mission,  or  cross-functionally  as 
Hurley  [2005:  91-96]  describes.  In  this  method,  the  staff  is  organized  into  separate 
autonomous  units,  each  for  a  particular  task  or  mission  [Forsberg,  Mooz,  &  Cotterman, 
2005:  171].  Each  unit  would  be  comprised  of  members  with  expertise  in  the  different 
functional  areas  required  for  the  project  or  mission.  The  members  of  the  project/mission 
staff  would  report  only  to  the  project/mission  leader  and  once  the  project/mission  was 
accomplished,  the  staff  would  be  disbanded.  Third,  a  staff  can  be  organized  according  to 
a  matrix  method,  in  other  words  a  combination  of  functional  and  project/mission.  In  this 
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method  there  are  leaders  or  managers  defined  for  both  projects/missions  and  functions. 
Staff  personnel  are  assigned  to  leaders  from  both  categories.  The  project/mission  leader 
defines  what  the  staff  personnel  should  do  while  the  functional  leader  defines  how  the 
staff  personnel  should  executed  their  work  [Forsberg,  Mooz,  &  Cotterman,  2005:  173]. 

c.  Personnel 

Personnel  are  persons  who  do  not  have  authority  over  or  responsibility  for 
a  portion  of  a  senior  commander’s  forces.  Personnel  can  be  delineated  in  at  least  two 
ways.  First,  personnel  can  be  divided  by  the  functions  they  perform.  Second,  personnel 
can  be  divided  by  their  status  (e.g.,  Navy,  Military,  DoD  Civilian,  Contractor,  Active 
Duty,  Reserve,  National  Guard). 

d.  Input  Interface 

An  input  interface  is  a  resource  which  connects  an  external  system  with 
the  C2  system.  As  discussed  in  Appendix  E:  Functional  Decomposition,  communication 
of  information  is  based  on  the  exchange  of  data  through  observation.  A  C2  system  input 
interface,  therefore,  transforms  inputs,  which  are  in  the  fonn  of  data,  into  useful 
information.  C2  system  input  interfaces  can  therefore  organized  by  the  medium  in  which 
the  data  is  received.  Examples  of  medium  divisions  are  electromagnetic,  voice,  acoustic 
sound,  electromechanical,  mechanical,  scent,  and  taste. 

e.  Output  Interface 

A  C2  system  output  interface  transforms  internal  information  into  the  form 
of  data  which  then  can  be  transported  or  transmitted  to  a  subsystem  or  an  external  system. 
Therefore,  C2  system  output  interfaces  can  be  organized  by  the  medium  in  which  the  data 
is  transported  or  transmitted.  Similar  to  input  interfaces,  examples  of  medium  divisions 
are  electromagnetic,  voice,  acoustic  sound,  electromechanical,  mechanical,  scent,  and 
taste. 
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f.  Processor 

The  purpose  of  the  processor  is  either  to  transform  information  or  convert 
data.  Example  instantiations  of  processors  include  human,  mechanical  analog, 
electromechanical  analog,  electromechanical  digital,  and  electronic  digital. 

g.  Memory/Storage 

Memory  is  a  component  for  storing  information  within  the  operating 
lifetime  of  the  C2  system  while  storage  is  a  component  for  storing  information  beyond 
the  operating  lifetime  of  the  C2  system.  Example  instantiations  of  memory  and  storage 
include  human,  mechanical,  electromechanical,  and  electromagnetic. 

It.  Link 

Links  connect  the  output  interface  of  a  subsystem  with  the  input  interface 
of  another  subsystem.  As  discussed  in  the  body  of  the  thesis,  instantiations  of  links  can 
be  described  by  the  type  of  connection  (i.e.,  physical  or  remote)  and  by  the  medium  in 
which  the  information  is  imbedded  (e.g.,  physical  matter,  acoustic,  electromagnetic). 

2.  Physical  Architecture  Procedures  and  Controls 

As  with  the  generic  physical  components,  the  morphological  box  technique  was 
used  to  generate  and  describe  the  multiple  instantiations  of  a  few  of  the  applicable 
procedures  and  controls.  The  top-level  morphological  box  for  procedures  and  controls  is 
presented  in  Table  10.  The  first  column  presents  the  generic  procedures  and  controls 
with  the  remaining  entries  in  each  row  denoting  the  specific  instantiations.  Details 
concerning  each  of  the  alternatives  for  each  of  the  procedures  and  controls  of  the  physical 
architecture  are  presented  in  the  discussions  below. 
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Table  10.  Procedures  and  Controls  Morphological  Box 
a.  Ethics 

Ethics  are  a  set  of  moral  principles  or  a  system  of  moral  values  [Misch, 


1994:  398],  For  the  purpose  of  this  thesis,  ethics  are  the  basis  by  which  the  morality  of 
an  option  or  decision  is  judged.  In  particular,  ethics  are  used  as  a  procedure  for  or  as  a 
control  on  the  function  Judge  Response  Options.  As  will  be  shown  in  the  development  of 
the  operational  architecture,  the  resource  assigned  Judge  Response  Options  is  human.  In 
essence,  this  thesis  took  the  approach  that  a  human  is  always  within  the  command  and 
control  process.  It  is,  therefore,  the  ethics  and  morals  of  such  human  that  is  a  procedure 
for  and  control  on  the  C2  system. 

There  are  at  least  three  general  approaches  to  ethics,  as  described  by 
Ackoff  [1989:  6].  First,  there  is  the  absolute  approach  in  which  the  judgment  of  morality 
is  detennined  by  compliance  to  a  rule.  Unfortunately,  as  Ackoff  [1989:  6]  states,  “No 
set  of  ethical-moral  rules  has  yet  been  formulated  which  does  not  lead  to  unresolvable 
problems.”  Second,  there  is  the  relativistic  approach  in  which  the  judgment  of  morality  is 
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determined  by  the  situation  and  entities  involved.  This  approach  also  raises  difficulties 
when  “what  is  ‘good’  for  one  person  is  ‘bad’  for  another”  [Ackoff,  1989:  8]  that  is 
involved.  The  final  approach  to  ethics  is  a  combination  of  both  of  the  previous 
approaches. 


b.  Rules  of  Engagement 

Rules  of  engagement  (ROE)  are  procedures  and  controls  which  specify 
how  and  to  what  limit  forces  will  initiate  or  continue  combat  engagement  with  other 
forces.  The  two  instantiations  of  rules  of  engagement  are  command  by  negation  and 
positive  command.  Command  by  negation  accounts  for  those  instances  where  the  ROE 
allow  actions  to  be  taken  “at  the  discretion  of  different  levels  of  command  unless  negated 
by  countennanding  orders  by  higher  command  or  by  political  authorities”  [George,  1984: 
227].  Positive  command  accounts  for  those  instances  where  the  ROE  allow  actions  to 
“taken  by  military  units  only  if  expressly  authorized  by  higher  command  or  by  political 
authorities  at  some  point  in  the  development  of  the  crisis”  [George,  1984:  227]. 

c.  Weapons  Control  Status 

Weapons  control  status  is  another  control  of  a  C2  system.  It  denotes  how 
and  on  which  classification  of  targets  weapons  systems  can  be  used.  Three  instantiations 
of  weapons  control  status  are  Free,  Tight,  and  Hold  [after  NATO  Standardization 
Agency,  2008:  2-W-2].  Free  denotes  that  weapons  systems  may  be  fired  at  any  target 
not  positively  recognized  as  friendly.  Tight  denotes  that  weapons  systems  may  be  fired 
only  at  targets  recognized  as  hostile.  Hold  denotes  that  weapons  systems  may  be  fired 
only  in  self-defense  or  by  formal  order  from  higher  authority. 

d.  Command  and  Control  Tactics,  Techniques,  and  Procedures 

Tactics,  techniques,  and  procedures  (TTPs)  for  C2,  though  a  bit  more 
descriptive  than  the  concept  of  C2  doctrine,  is  still  a  broad  topic.  For  purposes  of  this 
thesis,  C2  TTPs  were  decomposed  into  three  primary  categories  each  of  which  were 
comprised  of  four  conceptual  instantiations.  The  three  primary  categories  were 
situational  awareness,  decision  authority,  and  allocation  authority.  The  first  three 
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conceptual  instantiations  of  each  follow  Baran’s  [1964]  description  of  centralized, 
decentralized,  and  distributed  networks,  which  is  presented  visually  in  Figure  29.  Baran 
did  not  describe  the  fourth  instantiation  of  the  categories  since  he  was  attempting  to 
describe  a  connected  network  for  communications.  The  final  conceptual  instantiation  for 
situational  awareness  equates  roughly  to  solitariness  while  the  final  instantiation  for 
decision  authority  and  allocation  authority  is  anarchic. 
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Figure  29.  Centralized,  Decentralized,  Distributed,  and  Isolated 

[after  Baran,  1964:  2] 
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e.  Situational  Awareness 

Situational  awareness  is  a  category  to  group  TTPs  and  controls  which 
affect  the  sharing  and  dissemination  of  situational  information  within  the  networked 
force.  Centralized  situational  awareness  describes  the  instances  where  a  single  entity  or  a 
single  system  collects  and  disseminates  information  pertaining  to  the  situation. 
Decentralized  situational  awareness  describes  those  instances  where  the  sharing  of 
situational  information  is  divided  into  multiple  levels  with  single  line  of  communication. 
In  other  words,  an  entity  or  system  at  one  level  shares  situational  infonnation  with  a 
portion  of  entities  or  systems  at  a  lower  level  and  with  one  entity  or  system  at  a  higher 
level.  Centralized  situational  awareness  is  divided  into  only  two  levels  with  the  central 
entity  or  system  comprising  the  highest  level  which  shares  infonnation  with  all  lower 
level  entities  or  systems. 

Distributed  situational  awareness  describes  those  instances  where 
situational  information  from  one  entity  or  systems  is  shared  with  two  or  more  entities  or 
systems,  for  every  entity  or  system  in  the  networked  force.  Finally,  isolated  situational 
awareness  describes  those  instances  where  situational  information  is  not  shared  between 
any  entities  or  systems. 

f  Decision  Authority 

Decision  authority  is  a  category  to  group  TTPs  and  controls  that  affect  the 
decisions  within  the  networked  force,  which  are  applicable  to  the  changing  circumstances 
of  the  situation.  Centralized  decision  authority  describes  the  instances  where  a  single 
entity  or  a  single  system  is  authorized  to  make  decisions  for  the  networked  force. 
Decentralized  decision  authority  describes  those  instances  where  the  authority  to  make 
decisions  concerning  a  portion  of  the  network  force  follows  a  line  of  direct  superiors. 

That  is,  decision  authority  is  divided  into  levels  where  an  entity  at  one  level  has  authority 
over  a  portion  of  the  entities  at  a  lower  level  but  in  turn  receives  such  authority  by  one 
entity  at  a  higher  level.  Distributed  decision  authority  describes  those  instances  where 
the  authority  to  make  decisions  follows  multiple  lines  of  superiors.  In  other  words, 
decision  authority  over  an  entity  resides  in  two  or  more  entities  which  have  a  direct 
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connection  with  such  entity.  Anarchy  is  the  absence  of  any  authority  [Mish,  1994:  42]. 
Therefore,  anarchic  decision  authority  describes  those  instances  where  the  decision 
authority  resides  only  in  the  entity  itself,  for  all  entities  in  the  force. 

The  use  of  a  distributed  communications  system  to  transport  a  decision 
and  distributed  decision  authority  are  not  equivalent.  When  a  junior  relies  upon  the 
decision  of  one  superior,  even  if  the  decision  can  be  communicated  via  many  different 
means  and  methods,  decision  authority  is  not  distributed.  Decision  authority  in  such  case 
would  be  decentralized  or  centralized,  but  not  distributed.  The  same  holds  for  allocation 
authority. 


g.  Allocation  Authority 

Allocating  authority  is  a  category  to  group  applicable  TTPs  and  controls 
which  affect  the  allocation  of  roles  and  responsibilities  of  the  networked  force. 
Centralized  allocation  authority  describes  the  instances  where  a  single  entity  or  a  single 
system  is  authorized  to  allocate  roles  and  responsibilities  to  the  networked  force. 
Decentralized  allocation  authority  describes  those  instance  where  the  authority  to  allocate 
roles  and  responsibilities  is  divided  into  levels  where  an  entity  at  one  level  has  authority 
over  a  portion  of  the  entities  at  a  lower  level  but  in  turn  receives  such  authority  by  one 
entity  at  a  higher  level.  Distributed  allocation  authority  describes  those  instances  where 
the  authority  to  allocate  roles  and  responsibilities  to  an  entity  resides  in  two  or  more 
entities  which  have  a  direct  connection  with  such  entity.  Anarchic  allocation  authority 
describes  those  instances  where  the  authority  to  allocate  a  role  or  responsibility  to  an 
entity  resides  only  in  the  entity  itself,  for  all  entities  in  the  force. 

E.  ALTERNATIVE  PHYSICAL  ARCHITECTURES 

Once  instantiations  for  the  generic  components,  procedures,  and  controls  are 
identified  the  next  step  was  to  generate  multiple  physical  architectures  from  which  one  or 
more  could  be  selected  to  serve  as  an  input  to  the  operational  architecture.  Recall  that  a 
goal  of  this  thesis  was  to  better  understand  the  influence  of  doctrine  on  the  overall 
architecture  of  the  material  system  in  order  to  ensure  developing  net-centric  systems  and 
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net-centric  doctrine  meet  the  command  and  control  needs  of  tactical  naval  forces.  For 
this  thesis,  two  alternative  physical  architectures  were  developed  with  varying 
instantiations  of  doctrine.  When  possible,  all  other  components  (i.e.,  communications 
and  information  systems),  procedures,  and  controls  were  kept  the  same  between  the 
alternative  architectures  to  highlight  the  impact  of  doctrine.  Discussions  of  the  two 
alternative  architectures  are  presented  in  the  following  sections. 

1.  Alternative  Physical  Architecture  #1 

As  presented  previously,  the  focus  of  this  thesis  has  been  on  those  actions  a  future 
(i.e.,  ten  to  fifteen  years  from  present)  Surface  Action  Group  would  conduct  to  secure 
local  sea  control  in  traditional  operating  environments.  Currently,  U.S.  tactical  naval 
forces  operate  under  Composite  Warfare  Commander  (CWC)  doctrine  [Jane’s 
Information  Group,  2008].  Use  of  CWC  doctrine  dictates  several  of  the  physical 
architecture  instantiations.  First,  the  OTC’s  subordinate  commanders  are  organized  using 
a  functional-resource  combination.  This  is  seen  in  the  division  of  Principle  and 
Functional  Warfare  Commanders  and  Coordinators.  The  Warfare  Commanders  (both 
Principle  and  Functional)  can  be  delegated  decision  authority  to  respond  with  assigned 
assets.  Coordinators  are  delegated  allocation  authority.  Therefore,  both  decision 
authority  and  allocation  authority  are  decentralized.  The  Composite  Warfare 
Commander  structure  is  presented  in  Figure  30. 
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Composite  Warfare  Commander  Structure 
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Principal  Warfare  Commanders 


Air  Defense 
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(TSC) 

Figure  30.  Composite  Warfare  Commander  Structure 
[from  Jane’s  Information  Group,  2008] 

For  the  first  physical  architecture,  CWC  doctrine  as  currently  written  is  used. 
Instantiations  of  commanders,  decision  authority,  and  allocation  authority  follow 
accordingly.  In  addition,  the  concept  of  Cooperative  Engagement  Capability  (CEC), 
discussed  in  Chapter  II,  was  assumed  to  have  been  designed  and  implemented  not  only 
for  air  defense  but  for  surface  and  undersea  warfare  as  well.  The  concept  of  CEC,  as 
discussed  in  The  Cooperative  Engagement  Capability  [1995],  with  such  expansion  would 
dictate  distributed  situational  awareness.  Other  physical  architecture  instantiations 
include  the  functional  organization  traditionally  used  for  staff  and  personnel,  absolute 
approach  to  ethics,  adoption  of  command  by  negation,  and  a  weapons  control  status  of 
tight.  Key  physical  architecture  instantiations  described  above  for  the  first  physical 
architecture  are  highlighted  with  bold,  italic  font  in  Table  11. 
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Table  1 1 .  Alternative  Physical  Architecture  #1 


2.  Alternative  Physical  Architecture  #2 

For  the  second  physical  architecture  the  use  of  CWC  doctrine  as  currently  written 
is  not  used.  The  replacement  “doctrine”  under  consideration  for  this  thesis  dictates 
subordinate  commanders  to  be  organized  functionally  and  decision  and  allocation 
authority  to  be  distributed.  An  expanded  concept  of  CEC  is  still  assumed,  making 
situational  awareness  distributed.  The  remaining  physical  architecture  instantiations 
remain  consistent  with  the  first  alternative  physical  architecture  (selection  of  functional 
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organization  traditionally  used  for  staff  and  personnel,  absolute  approach  to  ethics,  the 
adoption  of  command  by  negation,  and  a  weapons  control  status  of  tight). 

Distributed  decision  authority  describes  those  instances  where  the  authority  to 
make  decisions  follows  multiple  lines  of  superiors.  Distributed  allocation  authority 
describes  those  instances  where  the  authority  to  allocate  roles  and  responsibilities  to  an 
entity  resides  in  two  or  more  entities  which  have  a  direct  connection  with  such  entity. 
The  key  physical  architecture  instantiations  described  above  for  the  second  physical 


architecture  are  highlighted  with  bold,  italic  font  in  Table  12. 
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Decentralized 

Distributed 

Isolated 

C2  TTP: 
Decision 
Authority 

Centralized 

Decentralized 

Distributed 

Anarchic 

C2  TTP: 
Allocation 
Authority 

Centralized 

Decentralized 

Distributed 

Anarchic 

Table  12.  Alternative  Physical  Architecture  #2 
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F.  CHAPTER  SUMMARY 

The  physical  architecture  describes  the  resources  which  comprise  the  system,  the 
procedures  by  which  the  system  is  used,  and  the  controls  on  the  system.  During  the 
development  of  the  physical  architecture,  which  is  done  concurrently  with  the 
development  of  the  functional  architecture,  generic  physical  components  and  generic 
procedures  and  controls  are  identified.  A  set  of  instantiations  is  developed  for  each 
component,  procedure,  and  control  from  which  alternative  physical  architectures  are 
developed.  Such  alternative  physical  architectures  and  other  products  of  the  first  three 
phases  of  the  system  architectural  process  provide  inputs  for  the  development  of  the 
operational  architecture. 
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VII.  OPERATIONAL  ARCHITECTURE 


A.  INTRODUCTION 

The  operational  architecture  provides  a  description  of  the  system  design, 
incorporating  the  products  of  the  operational  concept,  functional  architecture,  and 
physical  architecture.  Major  phases  of  the  operational  architecture  development  for  this 
thesis  were  to  allocate  functions  and  requirements  to  the  physical  components  and  to 
describe  the  activation  and  control  of  functions.  Analysis  of  the  designs  and  full 
documentation  of  the  architectures  are  subsequent  phases  of  the  operational  architecture 
which  were  omitted  due  to  the  scope  of  this  thesis.  The  feasibility  of  an  analysis  of 
designs  using  the  architectural  framework  developed,  however,  was  demonstrated  using 
modeling  and  simulation. 

B.  GENERIC  PHYSICAL  COMPONENT  FUNCTIONAL  ALLOCATION 

The  first  step  in  the  development  of  the  operational  architecture  is  the  allocation 
of  functions  from  the  functional  architecture  to  components  from  the  physical 
architecture.  The  initial  phases  of  this  process  are  conducted  in  conjunction  with  the  co¬ 
development  of  the  functional  hierarchy  and  the  generic  physical  architecture.  These 
allocations  are  represented  in  Figure  5 1 .  through  Figure  63.  in  Appendix  F:  Input- 
Output  Relationships. 

C.  FUNCTIONAL  FLOW,  ACTIVATION,  AND  CONTROL 

The  second  step  in  the  development  of  the  operational  architecture  is  to  define 
and  analyze  functional  activation  and  control  structures.  Recall  that  the  focus  of  this 
thesis  has  been  on  those  actions  a  future  (i.e.,  ten  to  fifteen  years  from  present)  Surface 
Action  Group  would  conduct  to  secure  local  sea  control  in  traditional  operating 
environments.  As  delineated  in  the  operational  concept,  one  task  a  SAG  securing  local 
sea  control  must  be  capable  of  executing  is  contact  prosecution.  Modeling  the  functional 
flow,  activation,  and  control  of  contact  prosecution  is  necessary  in  the  development  of  the 
operational  architecture.  Modeling  the  remaining  sub-tasks  and  tasks,  as  well  as  the  other 
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missions  and  their  respective  tasks  and  sub-tasks,  would  be  required  for  the  operational 
architecture  development.  Given  the  scope  of  this  thesis  and  the  magnitude  of  effort 
required  to  model  all  missions,  tasks,  and  sub-tasks  of  a  C2  system,  the  sub-task  of 
contact  prosecution  was  modeled  to  serve  as  an  example  for  future  development  of  the 
operational  architecture. 

The  contact  prosecution  process  was  detailed  for  both  of  the  alternative  physical 
architectures  developed.  The  contact  prosecution  functional  flow  for  both  physical 
architectures  was  the  same  and  is  presented  in  Figure  3 1 .  and  continued  in  Figure  32. 

The  remaining  collection  of  contact  prosecution  process  diagrams  are  presented  in 
Appendix  G:  Operational  Architecture. 

The  CPO  diagrams  present  the  interactions  of  the  system’s  top  level  functions 
from  the  functional  architecture,  the  selected  mechanisms  from  the  physical  architecture, 
and  the  procedures  and  controls  identified  in  the  physical  architecture.  First,  starting  in 
Figure  31.  ,  the  C2  system  accepts  inputs  from  external  sensor  systems,  weapon  systems, 
platforms,  and  people  (e.g.,  established  intent).  The  C2  system  then  processes  the  inputs, 
transports  the  resulting  information,  and  reprocesses  the  information  for  presentation  and 
response  option  generation.  The  current  and  past  circumstances,  as  well  as  established 
intent  when  available,  serve  as  inputs  for  generating  a  response  option.  The  response 
option  is  then  processed,  transported,  and  reprocessed  for  selection,  which  begins  in 
Figure  32. 

If  the  response  option  is  selected  it  becomes  a  response  which  is  then  processed, 
transported,  and  processed  again.  From  the  response  an  executable  response  is  created 
which  is  processed,  transported,  and  reprocessed  to  finally  produce  an  assignment  and/or 
warning  to  external  systems  and  people;  the  flow  through  the  figures  is  complete.  If  the 
response  option  was  not  selected,  it  would  be  processed,  transported,  and  reprocessed  to 
serve  as  input  to  generate  a  new  response  option,  as  shown  at  the  bottom-left  of  Figure 
31. 
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Figure  3 1 .  Contact  Prosecution  (CPOa) 
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Figure  32.  Contact  Prosecution  -  Continued  (CPOb) 
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Further  detail  of  the  functional  activation  and  control  for  the  top-level  functions  in 
the  contact  prosecution  process  is  presented  below  in  Table  13.  The  table  is  organized  by 
function,  output,  required  inputs,  and  required  controls.  Functions  with  multiple  outputs 
are  described  with  multiple  lines  in  the  output  column.  Outputs  that  can  be  generated  by 
different,  independent  inputs  are  described  with  multiple  lines  in  the  input  column. 
Outputs  that  require  two  or  more  inputs  are  described  by  listing  all  the  required  inputs  in 
one  line  in  the  input  column.  For  example,  the  Response  Option  output  from  Generate 
Response  Option  can  be  generated  by  multiple  combinations  of  inputs.  Response  Option 
can  be  generated  by  the  function  with  Current  Circumstances,  Past  Circumstances,  and 
Established  Intent.  Response  Option  can  also  be  generated  by  the  function  with  only 
Infeasible  Response.  Response  Option  can  be  generated  by  many  other  combinations  of 
inputs,  as  well.  Appendix  G:  Operational  Architecture  includes  the  complete  table  of  the 
activation  and  controls,  which  includes  sub-functions  of  the  contact  prosecution  process. 


Function  Output _  Required  Inputs _  Required  Controls 


Transport 

Information 

-  Transported  Data 

-  Transport  Data 

N/A 

-  Response  Option 

-  Communication  Protocols 

-  Response 

-  Communication  Protocols 

-  Order 

-  Communication  Protocols 

-  Expected  Circumstances 

-  Communication  Protocols 

-  Transport  Data 

-  Infeasible  Response 

-  Communication  Protocols 

-  Incomplete  Response 

-  Communication  Protocols 

-  Unassigned  Tasks 

-  Communication  Protocols 

-  Illegal  Response 

-  Communication  Protocols 

-  Immoral  Response 

-  Communication  Protocols 

-  Immoral  Tasks 

-  Communication  Protocols 

-  Past  Experiences 

-  Stored  Data 

-  Communication  Protocols 

-  Resources'  Capabilities 

-  Stored  Data 

-  Communication  Protocols 

Process 

Information 

-  Response  Option  Output 

-  Response  Option 

-  Communication  Protocols 

-  Response  Option  Data 

-  Communication  Protocols 

-  Assignment 

-  Transported  Data 

-  Communication  Protocols 

-  Warning 

-  Transported  Data 

-  Communication  Protocols 

-  Assignment  Output 

-  Transported  Data 

-  Communication  Protocols 

-  Warning  Output 

-  Transported  Data 

-  Communication  Protocols 

-  Circumstance  Output 

-  Transported  Data 

-  Communication  Protocols 

-  Intent  Output 

-  Transported  Data 

-  Communication  Protocols 

-  Response 

-  Transported  Data 

-  Past  Experiences 

-  Infeasible  Response 

-  Transported  Data 

-  Past  Experiences 

-  Incomplete  Response 

-  Transported  Data 

-  Past  Experiences 

-  Illegal  Response 

-  Transported  Data 

-  Past  Experiences 

-  Immoral  Response 

-  Transported  Data 

-  Past  Experiences 

-  Unassigned  Tasks 

-  Transported  Data 

-  Past  Experiences 

-  Immoral  Tasks 

-  Transported  Data 

-  Past  Experiences 
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-  Expected  Circumstances 

-  Transported  Data 

-  Past  Experiences 

-  Response  Option 

-  Transported  Data 

-  Past  Experiences 

-  Order 

-  Order 

-  Past  Experiences 

-  Current  Circumstances 

-  Transported  Data 

-  Past  Experiences 

-  Past  Circumstances 

-  Transported  Data 

-  Past  Experiences 

-  Established  Intent 

-  Transported  Data 

-  Past  Experiences 

Store 

Information 

-  Stored  Data 

-  Storage  Data 

N/A 

Present 

Information 

-  Presented  Data 

-  Assignment  Output 

-  HSI  Requirements 

-  Warning  Output 

-  HSI  Requirements 

-  Circumstance  Output 

-  HSI  Requirements 

-  Intent  Output 

-  HSI  Requirements 

-  Response  Option  Output 

-  HSI  Requirements 

Generate 

Response 

Options 

-  Response  Option 

-  Current  Circumstances 

-  Past  Circumstances 

-  Established  Intent 

-  Past  Experiences 

-  Law  of  Armed  Conflict 

-  Rules  of  Engagement 

-  Weapons  Control  Status 

-  No  Strike  List 

-  Restricted  Target  List 

-  Tactics,  Techniques,  and 
Procedures 

-  Pre-planned  Responses 

-  Resources'  Capabilities 

-  Current  Circumstances 

-  Expected  Circumstances 

-  Established  Intent 

-  Response 

-  Past  Experiences 

-  Law  of  Armed  Conflict 

-  Rules  of  Engagement 

-  Weapons  Control  Status 

-  No  Strike  List 

-  Restricted  Target  List 

-  Tactics,  Techniques,  and 
Procedures 

-  Pre-planned  Responses 

-  Resources'  Capabilities 

-  Established  Intent 

-  Infeasible  Response 

-  Past  Experiences 

-  Law  of  Armed  Conflict 

-  Rules  of  Engagement 

-  Weapons  Control  Status 

-  No  Strike  List 

-  Restricted  Target  List 

-  Tactics,  Techniques,  and 
Procedures 

-  Pre-planned  Responses 

-  Resources'  Capabilities 

-  Infeasible  Response 

-  Past  Experiences 

-  Law  of  Armed  Conflict 

-  Rules  of  Engagement 

-  Weapons  Control  Status 

-  No  Strike  List 

-  Restricted  Target  List 

-  Tactics,  Techniques,  and 
Procedures 

-  Pre-planned  Responses 

-  Resources'  Capabilities 
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-  Established  Intent 

-  Incomplete  Response 

-  Unassigned  Tasks 

-  Past  Experiences 

-  Law  of  Armed  Conflict 

-  Rules  of  Engagement 

-  Weapons  Control  Status 

-  No  Strike  List 

-  Restricted  Target  List 

-  Tactics,  Techniques,  and 
Procedures 

-  Pre-planned  Responses  - 
Resources'  Capabilities 

-  Incomplete  Response 

-  Unassigned  Tasks 

-  Past  Experiences 

-  Law  of  Armed  Conflict 

-  Rules  of  Engagement 

-  Weapons  Control  Status 

-  No  Strike  List 

-  Restricted  Target  List 

-  Tactics,  Techniques,  and 
Procedures 

-  Pre-planned  Responses 

-  Resources'  Capabilities 

-  Illegal  Response 

-  Past  Experiences 

-  Law  of  Armed  Conflict 

-  Rules  of  Engagement 

-  Weapons  Control  Status 

-  No  Strike  List 

-  Restricted  Target  List 

-  Tactics,  Techniques,  and 
Procedures 

-  Pre-planned  Responses 

-  Resources'  Capabilities 

-  Established  Intent 

-  Immoral  Response 

-  Immoral  Tasks 

-  Past  Experiences 

-  Law  of  Armed  Conflict 

-  Rules  of  Engagement 

-  Weapons  Control  Status 

-  No  Strike  List 

-  Restricted  Target  List 

-  Tactics,  Techniques,  and 
Procedures 

-  Pre-planned  Responses 

-  Resources'  Capabilities 

-  Immoral  Response 

-  Immoral  Tasks 

-  Past  Experiences 

-  Law  of  Armed  Conflict 

-  Rules  of  Engagement 

-  Weapons  Control  Status 

-  No  Strike  List 

-  Restricted  Target  List 

-  Tactics,  Techniques,  and 
Procedures 

-  Pre-planned  Responses 

-  Resources'  Capabilities 
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-  Required  Tasks 


-  Current  Circumstances 

-  Past  Circumstances 

-  Established  Intent 

-  Past  Experiences 

-  Law  of  Armed  Conflict 

-  Rules  of  Engagement 

-  Weapons  Control  Status 

-  No  Strike  List 

-  Restricted  Target  List 

-  Tactics,  Techniques,  and 
Procedures 

-  Pre-planned  Responses 

-  Current  Circumstances 

-  Expected  Circumstances 

-  Established  Intent 

-  Past  Experiences 

-  Law  of  Armed  Conflict 

-  Rules  of  Engagement 

-  Weapons  Control  Status 

-  No  Strike  List 

-  Restricted  Target  List 

-  Tactics,  Techniques,  and 
Procedures 

-  Pre-planned  Responses 

-  Established  Intent 

-  Infeasible  Response 

-  Past  Experiences 

-  Tactics,  Techniques,  and 
Procedures 

-  Pre-planned  Responses 

-  Established  Intent 

-  Incomplete  Response 

-  Unassigned  Tasks 

-  Past  Experiences 

-  Established  Intent 

-  Immoral  Response 

-  Immoral  Tasks 

-  Past  Experiences 

-  Unassigned  Tasks 

-  Incomplete  Response 

-  Past  Experiences 

-  Law  of  Armed  Conflict 

-  Rules  of  Engagement 

-  Weapons  Control  Status 

-  No  Strike  List 

-  Restricted  Target  List 

-  Tactics,  Techniques,  and 
Procedures 

-  Pre-planned  Responses 

-  Resources'  Capabilities 

-  Illegal  Response 

-  Past  Experiences 

-  Law  of  Armed  Conflict 

-  Rules  of  Engagement 

-  Weapons  Control  Status 

-  No  Strike  List 

-  Restricted  Target  List 

-  Tactics,  Techniques,  and 
Procedures 

-  Pre-planned  Responses 

-  Resources'  Capabilities 
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-  Immoral  Response 

-  Past  Experiences-  Law  of 
Armed  Conflict-  Rules  of 
Engagement-  Weapons 
Control  Status-  No  Strike 
List-  Restricted  Target 

List-  Tactics,  Techniques, 
and  Procedures-  Pre¬ 
planned  Responses- 
Resources'  Capabilities 

Select 

Response 

Options 

Executable  Response 

-  Response  Option 

-  Resources'  Capabilities 

-  Past  Experiences 

-  Established  Intent 

-  Required  Tasks 

-  Law  of  Armed  Conflict 

-  Rules  of  Engagement 

-  Weapons  Control  Status 

-  No  Strike  List 

-  Restricted  Target  List 

-  Tactics,  Techniques,  and 
Procedures 

-  Pre-planned  Responses 

-  Ethics 

-  Complete  Response 

-  Past  Experiences 

-  Required  Tasks 

-  Law  of  Armed  Conflict 

Expected  Circumstances 

-  Resources’  Capabilities 

-  Current  Circumstances 

-  Rules  of  Engagement 

-  Weapons  Control  Status 

-  No  Strike  List 

-  Restricted  Target  List 

Table  13.  Activation  and  Control  of  Top-level  Functions 


Since  the  contact  prosecution  functional  flow  for  both  physical  architectures  is  the 
same,  it  is  imperative  for  the  systems  engineer  to  describe  the  differences  in  the 
subsequent  operational  architectures  through  some  means.  Figure  33.  presents  a  notional 
flow  using  the  first  alternative  physical  architecture  while  Figure  34.  presents  a  notional 
flow  using  the  second  alternative  physical  architecture.  Many  of  the  details  developed 
during  the  previous  systems  engineer  process  (e.g.,  inputs,  outputs,  controls,  etc.)  are 
omitted  to  emphasize  the  differences  in  operational  architectures.  The  key  changes  in  the 
notational  flow  from  the  first  alternative  to  the  second  alternative  are  highlighted  with 
yellow  and  bold  boxes  in  Figure  34.  The  change  from  decentralized  to  distributed 
decision  authority  and  from  decentralized  to  distributed  allocation  authority  is  accounted 
for  by  including  multiple  entities  which  Select  Response  Options  in  parallel.  The 
distributed  situational  awareness,  in  both  architectures,  is  denoted  by  the  multiple  links  in 
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Transport  Information  and  their  associated  processors  in  Process  Information.  The 
significance  of  the  exclamation  points  will  be  discussed  in  the  following  section. 
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Figure  33.  Notional  Contact  Prosecution  Flow  -  Alternative  #1 
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Figure  34.  Notional  Contact  Prosecution  Flow  -  Alternative  #2 
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D.  ANALYSIS  OF  DESIGNS 


Analyses  of  the  system  designs  include  performance  analyses  and  risk  analyses. 
Performance  analyses  are  conducted  to  discover  “the  range  of  performance  that  can  be 
expected  from  a  specific  design  or  a  set  of  designs  that  are  quite  similar”  [Buede,  2000: 
267]  and  to  determine  if  a  particular  design  or  set  of  designs  can  achieve  a  related 
objective  from  the  objectives  hierarchy  and  its  associated  performance  parameters.  Risk 
analyses  examine  the  ability  of  the  design  or  set  of  designs  to  meet  the  desired  level  of 
performance  in  a  diverse  set  of  operational  scenarios  [Buede,  2000:  267].  In  many  cases, 
these  analyses  are  conducted  through  modeling  and  simulation. 

To  demonstrate  the  feasibility  of  using  the  developed  architectural  framework  to 
analyze  and  compare  alternative  designs,  Arena®,  version  10.0,  was  used.  Arena®  is  a 
discrete-event  modeling  and  simulation  software  developed  by  Rockwell  Automation, 
Inc.  A  portion  of  the  notional  contact  prosecution  flow  for  both  alternatives  was 
modeled;  the  portion  occurring  between  the  red  exclamation  points  as  shown  in  Figure 
33.  and  Figure  34.  The  top-level  of  the  Arena®  model  is  shown  in  Figure  35. 


Figure  35.  Top-level  of  Arena®  Contact  Prosecution  Model 
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In  both  models,  the  first  step  is  the  creation  of  a  response  option.  In  the 
Alternative  #1  model,  three  copies  of  the  response  option  are  created  and  transported 
using  three  different  links.  The  first  response  option  to  be  converted  and  processed  for 
use  is  then  used  as  input  for  the  first  time  through  Select  Response  Options.  Once  a 
response  is  selected,  three  copies  are  made  and  are  then  transported  using  three  different 
links.  The  first  response  to  be  converted  and  processed  for  use  is  then  used  as  an  input 
for  the  second  time  through  Select  Response  Options.  Finally,  an  executable  response  is 
generated  which  marks  the  end  of  the  Alternative  #1  Arena®  model. 

In  Alternative  #2  model,  nine  copies  of  the  response  option  are  created  and 
transported  using  nine  different  links;  three  links  associated  with  each  of  three  lines  of 
mechanisms  (e.g.,  subordinate  commanders)  to  Select  Response  Option.  The  first 
response  option  to  be  converted  and  processed  in  each  line  is  used  as  input  to  the  first 
Select  Response  Option  (i.e.,  Evaluate  Response  Options  and  Judge  Response  Options ). 
The  remaining  response  options  are  discarded.  Once  a  response  is  selected  by  each  line 
of  entities,  nine  copies  are  made  and  are  transported  using  nine  different  links;  three  links 
associated  with  each  of  three  lines  of  mechanisms  to  Select  Response  Option  a  second 
time  (i.e.,  Assign  Tasks  to  Resources).  Again,  the  first  response  to  be  converted  and 
processed  in  each  line  is  used  while  the  remaining  responses  are  discarded.  Finally,  an 
executable  response  is  generated  in  each  line  of  Select  Response  Option,  which  marks  the 
end  of  the  Alternative  #2  Arena®  model. 

Response  options  were  created  with  inter-arrival  times  following  an  exponential 
distribution.  Characteristics  and  attributes  of  processes  and  resources  were  kept  constant 
whenever  possible.  For  example,  the  time  for  a  subordinate  commander  to  judge  the 
morality  of  a  response  option  followed  the  same  distribution  (i.e.,  a  nonnal  distribution 
with  the  same  mean  and  variance)  for  all  subordinate  commanders  in  both  models. 
Further  details  concerning  characteristics  and  attributes  of  processes  and  resources,  and 
further  discussions  of  the  simulation  and  results,  is  presented  in  Appendix  G: 

Operational  Architecture. 

Perfonnance  of  each  alternative  system  designs  should  be  unique  and  it  is  the 

objective  of  discrete-event  modeling  and  simulation  to  identify  those  differences. 
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Differences  in  performance,  as  Buede  [2000:  267]  states,  are  almost  always  related  to  an 
objective  in  the  systems  objective  hierarchy  and  its  related  perfonnance  parameters. 
Given  that  a  significant  difference  between  the  two  alternative  system  designs  was  the 
change  from  decentralized  to  distributed  decision  authority  and  allocation  authority, 
differences  in  performance  of  the  alternatives  should  be  apparent  in  the  quality  of 
response  (i.e.,  the  fundamental  objectives  quality  of  response  decision  and  quality  of 
allocations). 

In  particular,  a  combination  of  three  MoMs  were  selected  to  highlight  differences 
in  perfonnance.  First,  the  sum  of  MoP  5. 2.2. 2,  time  between  response  option  being 
developed  and  response  decision,  and  MoP  6.2.1,  time  between  order  of  response 
execution  by  decision-authorized  entity  and  completion  of  allocations  by  allocation- 
authorized  entity,  was  recorded  for  each  alternative  design.  Second,  MoCE  5.5, 
consistency  of  response  between  decision-authorized  entities,  was  also  recorded.  These 
MoMs  were  selected,  in  part,  because  of  the  ability  of  Arena®  to  capture  the  statistics. 

Thirty  replications  were  conducted  for  each  alternative  model.  Each  replication 
began  with  a  warm-up  time  of  three  simulation-minutes  to  fill  queues  and  task  resources 
followed  by  ten  simulation-minutes  in  which  data  was  collected.  For  both  alternative 
models  approximately  100+  response  options  were  created  and  served  as  input  during  the 
ten  operational  simulation-minutes.  The  minimum  time  from  response  option  creation 
until  the  generation  of  an  associated  executable  response,  the  sum  of  MoP  5. 2.2. 2  and 
MoP  6.2.1,  was  recorded  for  each  response  option  and,  in  the  case  of  Alternative  #2,  for 
each  line  of  Select  Response  Option  mechanisms.  In  addition,  for  Alternative  #2,  the 
executable  responses  for  each  response  option  were  compared  to  determine  consistency 
(i.e.,  MoCE  5.5).  An  overview  of  the  simulation  results  is  presented  in  Table  14. 


Alternative  #1 

Alternative  #2 

Sample  Mean  of  Minimum  Time  (sec) 

16.313 

14.955 

Sample  Standard  Deviation  of  Minimum  Time 

1.382 

2.630 

Mean  percentage  of  grouped  Executable 
Responses  which  are  consistent 

100% 

86.6% 

Table  14.  Arena®  Simulation  Results  -  Overview 
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A  box  plot  of  the  simulation  results  data  is  presented  in  Figure  36.  Circles  denote  mild 
outliers  and  asterices  denote  extreme  outliers.  Further  results  of  the  simulations  are 
presented  in  Appendix  G:  Operational  Architecture. 


Simulation  Results 


Figure  36.  Arena®  Simulation  Results  -  Box  Plot 

Alternative  #2  generates  executable  responses,  on  average,  in  less  time  than 
Alternative  #1,  but  with  more  variance.  In  addition,  Alternative  #2  generates  consistent 
executable  responses  approximately  87%  of  the  time.  Since  Alternative  #1  generates 
only  one  executable  response  for  each  response  option,  the  consistency  of  response  is 
100%  by  default.  Through  hypothesis  testing  of  the  data  collected,  difference  in  the 
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mean  minimum  time  was  determined  to  be  statistically  significant.  This  demonstrates  the 
possible  performance  differences  between  the  two  alternative  designs. 

The  reader  is  warned  not  to  draw  specific  conclusions  on  performance  of  the 
alternative  system  designs  from  the  modeling  and  simulation  results  presented  above. 

The  objective  of  the  modeling  and  simulation  was  not  to  conduct  an  analysis  of  design, 
but  rather  demonstrate  the  feasibility  of  using  the  developed  architectural  framework  to 
conduct  such  analyses  and  compare  alternative  designs.  Asserting  performance 
superiority  of  one  alternative  over  another  should  not  be  done  for  several  reasons. 

First  and  foremost,  characteristics  and  attributes  of  the  processes  and  resources 
were  determined  by  the  author  and  not  by  data  collection  or  experimentation.  For  this 
reason  statistically  significant  differences  between  designs  apply  only  to  the  models 
developed  and  operationally  significant  differences  cannot  be  assessed.  Second,  the 
modeling  method  used  omitted  many  of  the  procedures  and  controls  on  the  system 
identified  in  the  architectural  development.  In  other  words,  the  models  were  a  further 
abstraction  of  an  already  conceptual  process. 

Third,  the  Alternative  #2  model  developed  was  only  one  instance  of  the  design 
solution  space  (i.e.,  the  selection  of  three  subordinated  commanders  and  three  processors 
in  Select  Response  Options)  possible  from  the  operational  architecture.  Fourth,  a  value 
structure  of  value  curves  and  weights  for  the  systems  objective  hierarchy  [Buede,  2000: 
Chapter  6],  upon  which  trade-off  decisions  should  be  based,  was  not  developed.  Fifth, 
and  finally,  the  above  modeling  and  simulation  represents  only  a  few  MoMs  for  only  one 
sub-task  out  of  numerous  tasks  and  missions  required  of  a  Surface  Action  Group  (SAG) 
to  secure  local  sea  control. 

E.  CHAPTER  SUMMARY 

The  operational  architecture  presented  provides  a  description  of  the  system  design 
by  incorporating  the  products  of  the  operational  concept,  functional  architecture,  and 
physical  architecture.  First,  functions  were  allocated  to  the  physical  components. 

Second,  the  activation  and  control  of  the  functions  were  described.  Finally,  the  feasibility 
of  an  analysis  of  designs,  using  the  architectural  framework  developed,  was  demonstrated 
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using  modeling  and  simulation.  Further  research  to  complete  the  operational  architecture 
and  concerning  the  analysis  of  designs  is  discussed  in  Chapter  VIII. 
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VIII.  CONCLUSION 


A.  SUMMARY 

This  thesis  dissected  the  complex  engineering  process  of  naval  tactical  command 
and  control  systems  to  identify  the  points  of  integration  between  doctrine  and  material. 
The  goal  was  to  better  understand  the  influence  of  doctrine  on  the  overall  architecture  of 
the  material  system  to  ensure  developing  net-centric  systems  and  net-centric  doctrine 
meet  the  command  and  control  needs  of  tactical  naval  forces.  To  begin  such  study,  this 
thesis  presented  concepts  of  command  and  control  developed  by  military  leaders  and 
enthusiasts  throughout  history.  Following  this  historical  review,  the  thesis  progressed 
through  the  system  architectural  methodology  developed  by  Alexander  Levis  as 
presented  by  Buede  [2000]  and  Levis  and  Wagenhals  [2000], 

The  first  phase  in  the  architectural  process  was  the  development  of  the  operational 
concept.  The  operational  concept  was  a  general  vision  of  the  system  from  the  view  of 
stakeholders  [Buede,  2000],  It  identified  the  boundaries  of,  inputs  to,  outputs  from, 
objectives  for,  and  requirements  of  the  system.  The  second  phase  in  the  architectural 
process  was  the  co-development  of  the  functional  architecture  and  the  physical 
architecture. 

The  purpose  of  the  functional  architecture  was  to  describe  what  the  system  was  to 
do  with  the  identified  inputs  to  produce  the  desired  outputs.  The  functional  architecture 
described  a  hierarchy  of  the  system’s  functions  and  detailed  the  relationships  between  the 
inputs  and  outputs  of  the  system  (i.e.,  described  the  sequence  of  functions  converting  an 
input  into  an  output).  The  purpose  of  the  physical  architecture  was  to  describe  the 
resources  that  comprised  the  system,  with  resources  for  every  function  identified  in  the 
functional  architecture  [Buede,  2000:  215-216].  In  addition,  the  physical  architecture 
described  the  procedures  by  which  the  system  was  used  [Buede,  2000:  218]  and  the 
controls  on  the  system.  Alternative,  instantiated  physical  architectures  were  also 
developed  as  potential  designs  of  the  system.  From  such  point  the  final  phase  of  the 
architectural  process,  the  development  of  the  operational  architecture,  began. 
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The  operational  architecture  provided  a  description  of  the  system  design  by 
incorporating  the  products  of  the  operational  concept,  functional  architecture,  and 
physical  architecture.  First,  the  functions  developed  in  the  functional  architecture  were 
allocated  to  the  physical  components  developed  in  the  physical  architecture.  Second,  the 
activations  and  controls  of  the  functions  were  described  in  a  framework  of  the  contact 
prosecution  process,  a  use  of  a  C2  system  identified  in  the  operational  concept.  The 
following  sections  of  this  chapter  present  key  points  and  recommendations  identified 
during  the  process  of  this  thesis  as  well  as  potential  areas  for  further  research. 

B.  KEY  POINTS  AND  RECOMMENDATIONS 

During  the  process  of  this  thesis,  several  key  points  were  identified  which  are 
crucial  for  understanding  the  influence  of  doctrine  on  the  overall  architecture  of  a  naval 
tactical  command  and  control  system.  The  first  key  point,  identified  in  Chapter  II,  was 
that  the  overall  process  of  command  and  control  and  the  process  internal  to  the  C2  system 
are  not  the  same.  Rather,  a  C2  system  is  the  means  by  which  the  C2  process  is  executed. 
This  had  implications  at  several  points  in  the  architectural  process.  First,  it  impacted  the 
view  of  what  was  internal  and  what  was  external  to  the  C2  system  (described  in  the 
operational  concept).  The  view  of  what  was  internal  to  the  C2  system  impacted  the 
identified  resources  of  the  C2  system  (detailed  in  the  physical  architecture).  The  view  of 
what  was  external  to  the  C2  system  impacted  the  identified  inputs  and  outputs  and 
subsequently  the  functions  of  a  C2  system  (detailed  in  the  functional  architecture). 

The  second  key  point,  following  from  the  first,  is  that  doctrine  has  significant 
impact  on  each  phase  of  the  system  architectural  process.  In  the  operational  concept, 
doctrine  impacts  which  missions  and  tasks  a  naval  force  is  expected  to  execute.  It  also 
impacts,  as  discussed  above,  the  view  of  the  system’s  boundaries.  In  the  functional 
architecture,  doctrine  impacts  what  functions  a  C2  system  must  accomplish.  In  the 
physical  architecture,  doctrine  impacts  the  resources,  or  mechanisms,  available  and  how 
they  are  assigned  to  functions.  Additionally,  doctrine  impacts  controls  on  mechanisms 
and  the  types  of  resources  which  execute  a  function  (e.g.,  only  humans  can  determine 
morality  of  a  response).  Finally,  in  the  operational  architecture,  doctrine  impacts  what 
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alternative  physical  architectures  are  considered  for  combination  with  the  functional 
architecture  (e.g.,  whether  a  single  commander  or  multiple  commanders  have  decision 
making  and/or  allocation  authority). 

The  author  recommends  that  systems  engineers  and  analysts  adopt  the  conceptual 
view  that  the  commander  is  outside  of  the  command  and  control  system  during  design, 
development,  and  simulation.  First,  this  view  addresses  the  function-process-system 
view  presented  in  historical  and  doctrinal  publications;  command  is  a  function  by  which  a 
responsible  entity  takes  inputs  (e.g.,  mission  objective,  assigned  forces,  operating 
environment,  adversary’s  capabilities,  etc.)  to  produce  the  desired  output  (i.e., 
accomplishment  of  the  mission  objective),  command  and  control  is  the  process  by  which 
the  inputs  generate  the  outputs,  and  a  C2  system  is  the  means  by  which  the  process  is 
executed.  Second,  this  view  enables  the  use  of  a  C2  system  and  the  execution  of  the  C2 
process  despite  those  situations  when  no  specific  entity  is  designated  responsible  for  the 
accomplishment  of  a  mission. 


Figure  37.  Command  and  Control:  Function-Process-System 
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The  author  also  recommends  the  use  of  the  selected  measures  of  merit,  developed 
in  the  operational  concept,  for  measuring  the  effectiveness  of  network-centric  command 
and  control  systems.  These  measures  of  merit  were  an  aggregation  of  measures  and 
concepts  presented  in  numerous  publications  and  were  selected  due  to  their  alignment 
with  the  network-centric  refined  problem  statement: 

A  responsive  and  robust  command  and  control  system  which  connects 
dispersed  forces  and  enables  such  forces  to  self-synchronize  and  allocate 
resources  to  mass  effects  in  order  to  meet  the  established  intent  at  the 
tactical  level  of  war. 


These  selected  measures  of  merit  are  presented,  again,  in  Table  15. 


1.2.1 

MoP 

Number  of  sources  confirming  information 

1.3.1 

MoP 

Time  between  changing  circumstances  and  observation 

1.3.2 

MoP 

Time  between  the  observation  and  the  completion  of  processing  the  data  into 
information 

1.3. 4. 4 

MoP 

Probability  of  shelf-life  is  less  than  time  between  updates 

1.4. 1.2 

MoP 

Percentage  of  nodes  which  are  capable  of  viewing  information 

1. 4.2.2 

MoP 

Percentage  of  nodes  which  are  capable  of  acting  on  information 

1.5. 2. 4 

MoP 

Percentage  of  Essential  Elements  of  Information  (EEI)  met 

1.5. 2. 5 

MoP 

Percentage  of  commander’s  Essential  Elements  of  Friendly  Information  (EEFI)  met 

1.8.1. 1 

DP 

Spatial  resolution  of  observation  capability 

1.8. 1.2 

DP 

Temporal  resolution  of  observation  capability 

1.9.2 

MoP 

Number  of  nodes  in  the  life  of  the  information  to  which  it  can  be  attributed 

1.9.1 

MoP 

Differential  between  time  information  is  received  by  a  node  and  when  information  can 
be  attributed 

2.1. 1.2 

MoP 

Percentage  of  total  decision-authorized  entities  that  are  available  via  existing 
relationships  and  connections 

2.1. 1.3 

MoP 

Percentage  of  total  allocation-authorized  entities  that  are  available  via  existing 
relationships  and  connections 

2.1. 1.4 

MoP 

Percentage  of  total  action-authorized  entities  that  are  available  via  existing  relationships 
and  connections 

2. 1.2. 1.2 

MoP 

Time  between  operational  failures  for  the  network  of  connections 

2.1.2.2.2 

MoP 

Probability  of  operational  failure  for  network  of  connections 

2.3.3. 1.2 

MoP 

Quantity  of  overflow  beyond  capacity  for  the  network  of  relationships  and  connections 

2.4.1. 1.4 

MoP 

Total  geographical  volume  of  relationships  and  connections 

2.4.2.1.3 

MoP 

Median  time  required  to  reconfigure  relationships  and  connections  to  meet  changing 
circumstances  and/or  necessary  responses 

2. 4. 2.2 

MoP 

Number  of  possible  solutions  for  required  reconfiguration  to  meet  changing 
circumstances  and/or  necessary  responses 

2.4.3. 1.4 

MoP 

Median  percentage  of  nodes  which  each  relationship  or  connection  is  capable  of 
connecting  with 

2.4.4. 1.3 

MoP 

Number  of  nodes  the  network  of  connections  are  capable  of  adding 

2.4. 4.2.7 

MoP 

Median  time  required  to  add  all  relationships  and  connections  to  meet  changing 
circumstances  and/or  necessary  responses 

2.4.5. 1.3 

MoP 

Median  geographical  range  nodes  can  maneuver  while  maintaining  needed  relationships 
or  connections 

3.2 

MoP 

Consistency  of  established  intent  between  forces 
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4.2 

MoP 

Consistency  of  awareness  between  forces  of  rules  and  constraints  which  are  applicable 
to  such  forces 

5.1.2 

MoP 

Consistency  of  response  with  established  intent 

5.1.4 

MoP 

Consistency  of  response  with  rules  and  constraints 

5.2.1 

MoP 

Time  between  receipt  of  information  concerning  changing  circumstances  and 
acknowledgement  of  receipt 

5.2.2. 1 

MoP 

Time  between  acknowledgement  of  receipt  of  information  concerning  changing 
circumstances  and  response  option  being  developed 

5.2.22 

MoP 

Time  between  response  option  being  developed  and  response  decision 

5.2.3 

MoP 

Time  between  response  decision  and  order  of  response  execution  by  decision- 
authorized  entity 

5.3.2 

MoP 

Median  number  of  connections  between  decision-authorized  entity  and  action- 
authorized  entity 

5.3.4 

MoP 

Percentage  of  entities  connected  by  existing  relationships  and  connections  which  are 
authorized  to  make  a  specific  decision  concerning  a  specific  change  in  circumstances 

5.4.1 

MoP 

Number  of  distinct  response  solutions  generated  by  decision-authorized  entities 
concerning  a  specific  change  in  circumstances 

5.5.2 

MoP 

Percentage  of  action-authorized  entities  with  conflicting  orders  from  decision- 
authorized  entities 

6. 1.3. 3 

MoP 

Percentage  of  action-authorized  entities  which  are  allocated  a  role  or  responsibility 
which  they  cannot  accomplish 

6.2.1 

MoP 

Time  between  order  of  response  execution  by  decision-authorized  entity  and  completion 
of  allocations  by  allocation-authorized  entity 

6.2.2 

MoP 

Time  between  allocation  of  role  or  responsibility  and  commencement  of  role  or 
responsibility  by  action-authorized  entity 

6.3.2 

MoP 

Median  number  of  connections  between  allocation-authorized  entity  and  action- 
authorized  entity 

6.3.4 

MoP 

Percentage  of  entities  connected  by  existing  relationships  and  connections  which  are 
authorized  to  make  allocations  concerning  a  specific  decision 

6.4.2 

MoP 

Percentage  of  roles  and  responsibilities  which  are  required  for  the  specific  decision 
which  are  not  allocated 

Table  15.  Selected  Measures  of  Merit 

C.  AREAS  FOR  FURTHER  RESEARCH 


The  approach  and  results  of  the  thesis  demonstrated  only  a  portion  of  the  system 
engineering  process  (i.e.,  system  architecture  phases)  focused  on  a  small  portion  of  the 
command  and  control  problem  (i.e.,  the  needs  of  a  Surface  Action  Group  tasked  to  secure 
local  sea  control  in  traditional  operating  environments),  all  at  a  highly  conceptual  level. 
This  thesis,  its  approach,  and  its  conclusions  provide  future  researchers  with  numerous 
areas  of  potential  study. 

First,  given  that  the  focus  of  this  thesis  was  on  the  interaction  of  doctrine  and 
material  in  the  system  architecture  process,  this  thesis  can  serve  as  an  example  for  further 
research  on  the  implications  of  organization,  training,  leadership,  personnel,  and  facilities 
on  the  system  engineering  process.  Second,  future  researchers  could  expand  the 
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presented  architectural  products  to  include  other  missions,  tasks,  forces,  and  scenarios. 
Third,  future  researchers  may  consider  validating  the  proposed  hierarchy  of  systems 
objectives.  This  can  be  done  through  a  survey  of  potential  stakeholders  or  through  an 
analysis  of  alternatives. 

Fourth,  future  researchers  may  consider  identifying  the  best  method  to  model  the 
architecture  framework  presented  in  this  thesis  in  order  to  simulate  the  alternative  C2 
systems.  Though  this  thesis  presented  one  method  for  modeling  and  simulating  the 
system  (i.e.,  discrete-event  modeling  and  simulation  using  Arena®)  it  should  not  be 
accepted  as  the  best  method.  Future  researchers  could  conduct  a  trade-off  study  of 
methods  and  tools  to  model  and  then  simulate  the  architectural  framework  developed. 
Fifth,  future  researches  could  develop  additional  alternative  system  architectures  using 
the  framework  developed.  Sixth,  and  finally,  future  researchers  could  analyze  the  two 
alternative  architectures  presented,  or  any  additionally  developed,  using  either  the  models 
presented  or  other  models  developed  in  the  future. 

D.  FINAL  SUMMARY 

The  systems  engineer,  among  other  things,  must  elicit  the  operational  needs  of  the 
customer  and  develop  a  system  architecture  from  which  specialized  engineers  can  design 
and  build  the  applicable  configurable  items.  Network-Centric  Warfare  (NCW)  is  an 
operational  concept  the  U.S.  military  has  identified  to  meet  its  operational  needs  which 
has  major  implications  on  the  development  of  command  and  control  systems.  This  thesis 
was  conducted  in  part  to  provide  a  better  understanding  of  the  influence  of  doctrine  on 
the  overall  architecture  of  command  and  control  system.  In  addition,  it  was  intended  to 
assist  in  the  development  and  integration  of  net-centric  systems  and  net-centric  doctrine 
to  meet  the  command  and  control  needs  of  future  tactical  naval  forces. 
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APPENDIX  A:  SCENARIO  DEVELOPMENT 


The  three  settings  and  a  collection  of  associated  scenarios  developed  are 
presented  below.  Some  scenarios,  and  portions  of  particular  scenarios,  are  omitted  due  to 


dissemination  limitations  on  information  from  references  used  in  development. 


ALPHA 

Anti-submarine  Warfare  (ASW)  +  Surface  Warfare  (SUW)  j 

Setting 

The  year  is  2020.  Country  BROWN  (a  U.S.  adversary) 
submarines  are  suspected  to  be  operating  in  the  vicinity  of  the 
STRAIT  OF  CONCERN,  which  lies  between  Country  GREEN  (a 
U.S.  ally)  and  BROWN.  A  U.S.  Navy  Surface  Action  Group 
(SAG)  is  tasked  with  maintaining  local  sea  control  of  the  STRAIT 
OF  CONCERN  for  the  potential  transit  of  high  value  units.  While 
conducting  anti-submarine  operations  in  the  strait,  the  SAG  is 
confronted  with  a  threatening  swarm  of  small  boats  emanating 
from  BROWN’s  national  waters.  The  SAG  must  continue  anti¬ 
submarine  operations  while  addressing  the  swann  of  small  boats. 
The  year  is  2020.  The  SAG  consists  of  1  CG  and  2  DDG. 

Actors  -  Systems 
&  Stakeholders 

Officer  in  Tactical  Command  (OTC) 

Combatant  Commander 

Submarine 

Swarm  Boats 

Sensor  System 

ASW  Platform 

Common  Tactical  Picture  (CTP)  system 

Weapon  System 

Flow  of  events 

1.  Combatant  Commander  issues  OPORD  to  OTC 

2.  OTC  assigns  sensor  systems  to  search  for  undersea  targets 

3.  OTC  assigns  sensor  systems  to  search  for  surface  targets 

4.  OTC  assigns  sensor  systems  to  search  for  air  targets 

5.  OTC  assigns  sensor  systems  to  search  for  electronic  warfare 
targets 

6.  CTP  system  alerts  OTC  of  probable  undersea  target  and 
location  [a,  b]. 

7.  OTC  assigns  additional  sensor  systems  to  probable  undersea 
target  for  confirmation  [a,  b]. 

8.  CTP  system  provides  confirmation  of  undersea  target  to  OTC 
[a,  b]. 

9.  OTC  assigns  sensor  system(s)  to  continually  track  the 
confirmed  undersea  targets  [a,  b] . 

10.  OTC  validates  confirmed  undersea  target  complies  with 
guidance,  LOAC,  ROE,  and  other  restrictions  [a,  b]. 

11.  OTC  detennines  desired  effect  (DETERRENCE)  against 
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confirmed  undersea  target  [a,  b]. 

12.  Potential  deterrence  options  are  generated  and  are  presented  to 
OTC  [a,  b]. 

13.  OTC  conducts  risk  assessment  of  deterrence  options  [a]. 

14.  OTC  orders  ASW  platform  to  proceed  to  confirmed  undersea 
target  as  a  deterrence  [a,  b]. 

15.  OTC  reviews  status  of  the  confirmed  undersea  target  noted  in 
CTP  system  [a,  b]. 

16.  OTC  assesses  deterrence  effectiveness  of  confirmed  undersea 
target  and  detennines  whether  to  engage  confirmed  undersea 
target  [a,  b], 

17.  CTP  system  alerts  OTC  of  probable  surface  targets  and 
location  [a], 

18.  OTC  assigns  additional  sensor  systems  to  probable  surface 
targets  for  confirmation  [a]. 

19.  CTP  system  provides  confirmation  of  surface  targets  to  OTC 
[a]. 

20.  OTC  assigns  sensor  system(s)  to  continually  track  the 
confirmed  surface  targets[a], 

21.  OTC  validates  confirmed  surface  targets  comply  with 
guidance,  LOAC,  ROE,  and  other  restrictions  [a]. 

22.  OTC  determines  desired  effect(s)  against  confirmed  surface 
targets  [a]. 

23.  Potential  engagement  options  are  generated  through  weapon- 
target  pairings  (WTPs)  and  are  presented  to  OTC  [a]. 

24.  OTC  conducts  risk  assessment  of  engagement  options  [a]. 

25.  OTC  orders  confirmed  surface  targets  to  be  engaged  with 
selected  engagement  option  [a]. 

26.  OTC  reviews  status  of  the  confirmed  surface  targets  noted  in 
CTP  system  [a]. 

27.  OTC  assesses  status  of  the  confirmed  surface  targets  and 
detennines  whether  to  re-engage  [a]. 

Inputs 

Probable  Target  Detection 

Probable  Target  Location 

Target  Confirmation 

Precise  Location  of  Confirmed  Target 

Confirmed  Target  Window  of  Vulnerability 

Refined  Window  of  Vulnerability  for  Confirmed  Target 

Engagement  Options 

Deterrence  Options 

Outputs 

Deterrence  Order 

Engagement  Order 

Re-engagement  Order 

References 

a.  JP  3-60:  Joint  Targeting  (2007) 
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b.  Bindi,  V.C.,  Baker,  J.,  Billington,  R.,  Gallassero,  T.,  Gueary, 
J.,  Harts,  et  al.  (1997). _ 

Table  16.  Scenario  ALPHA  -  1 


BRAVO 

Anti-submarine  Warfare  (ASW)  +  Air  Defense  (AD)  1 

Setting 

Country  BROWN  (a  U.S.  adversary)  submarines  are  suspected  to 
be  operating  in  the  vicinity  of  the  STRAIT  OF  CONCERN,  which 
lies  between  Country  GREEN  (a  U.S.  ally)  and  BROWN.  A  U.S. 
Navy  Surface  Action  Group  (SAG)  is  tasked  with  maintaining 
local  sea  control  of  the  STRAIT  OF  CONCERN  for  the  potential 
transit  of  high  value  units.  While  conducting  anti-submarine 
operations  in  the  strait,  the  SAG  is  confronted  with  several 
incoming  cruise  missiles  emanating  from  BROWN’s  national  air 
space.  The  SAG  must  continue  anti-submarine  operations  while 
addressing  the  cruise  missiles. 

The  year  is  2020.  The  SAG  consists  of  1  CG  and  2  DDG. 

Actors  -  Systems 
&  Stakeholders 

Officer  in  Tactical  Command  (OTC) 

Combatant  Commander 

Submarine 

Cruise  Missiles 

Sensor  System 

ASW  Platform 

Common  Tactical  Picture  (CTP)  system 

Weapon  System 

Flow  of  events 

1 .  Combatant  Commander  issues  OPORD  to  OTC 

2.  OTC  assigns  sensor  systems  to  search  for  undersea  targets 

3.  OTC  assigns  sensor  systems  to  search  for  surface  targets 

4.  OTC  assigns  sensor  systems  to  search  for  air  targets 

5.  OTC  assigns  sensor  systems  to  search  for  electronic  warfare 
targets 

6.  CTP  system  alerts  OTC  of  probable  undersea  target  and 
location  [a,  a]. 

7.  OTC  assigns  additional  sensor  systems  to  probable  undersea 
target  for  confirmation  [a,  a]. 

8.  CTP  system  provides  confirmation  of  undersea  target  to  OTC 
[a,  a], 

9.  OTC  assigns  sensor  system(s)  to  continually  track  the 
confirmed  undersea  targets  [a,  a], 

10.  OTC  validates  confirmed  undersea  target  complies  with 
guidance,  LOAC,  ROE,  and  other  restrictions  [a,  a]. 

1 1 .  OTC  determines  desired  effect(s)  against  confinned  undersea 
target  [a,  a]. 

12.  Potential  deterrence  options  are  generated  and  are  presented  to 
OTC  [a,  a], 

13.  OTC  conducts  risk  assessment  of  deterrence  options  [a,  a]. 
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14.  OTC  orders  ASW  platfonn  to  proceed  to  confirmed  undersea 
target  as  a  deterrence  [a,  a]. 

15.  OTC  reviews  status  of  the  confirmed  undersea  target  noted  in 
CTP  system  [a,  a]. 

16.  OTC  assesses  deterrence  effectiveness  of  confirmed  undersea 
target  and  determines  whether  to  engage  confirmed  undersea 
target  [a,  a]. 

17.  CTP  system  alerts  OTC  of  probable  air  targets[a]. 

18.  OTC  assigns  additional  sensor  systems  to  probable  air  targets 
for  confirmation  [a]. 

19.  CTP  system  provides  confirmation  of  air  targets  to  OTC  [a]. 

20.  OTC  assigns  sensor  system(s)  to  continually  track  the 
confirmed  air  targets[a]. 

21.  OTC  validates  air  targets  comply  with  guidance,  LOAC,  ROE, 
and  other  restrictions  [a]. 

22.  OTC  determines  desired  effect(s)  against  the  confirmed  air 
targets  [a], 

23.  Potential  engagement  options  are  generated  through  weapon- 
target  pairings  (WTPs)  and  are  presented  to  OTC  [a]. 

24.  OTC  conducts  risk  assessment  of  engagement  options  [a]. 

25.  OTC  orders  to  engage  confirmed  air  targets  with  selected 
engagement  option  [a]. 

26.  OTC  reviews  status  of  the  air  targets  noted  in  CTP  system  [a]. 

27.  OTC  assesses  status  of  the  air  targets  and  determines  whether 
to  re-engage  [a]. 

Inputs 

Probable  Target  Detection 

Probable  Target  Location 

Target  Confirmation 

Precise  Location  of  Confirmed  Target 

Confirmed  Target  Window  of  Vulnerability 

Refined  Window  of  Vulnerability  for  Confirmed  Target 

Engagement  Options 

Deterrence  Options 

Outputs 

Deterrence  Order 

Engagement  Order 

Re-engagement  Order 

References 

a.  JP  3-60:  Joint  Targeting  (2007) 

b.  Bindi,  V.C.,  Baker,  J.,  Billington,  R.,  Gallassero,  T.,  Gueary,  J., 
Harts,  et  al.  (1997). 

Table  17.  Scenario  BRAVO  -  1 


118 


CHARLIE  Maritime  Interception  Operations  (MIO)  +  Surface  Warfare  (SUW) 


Setting  Country  BLACK  is  suspected  of  harboring  anti-U.S.  terrorist.  The 

anti-U.S.  terrorists  are  suspected  of  attempting  to  smuggle  weapons 
of  mass  destruction  through  the  STRAIT  OF  CONCERN,  which 
lies  between  country  GREEN  (a  U.S.  ally)  and  country  BROWN  (a 
U.S.  ally),  via  commercial  shipping  carriers.  A  U.S.  Navy  Surface 
Action  Group  (SAG)  is  tasked  with  conducting  maritime 
interception  operations  (MIO)  in  the  vicinity  of  the  STRAIT  OF 
CONCERN  in  response  to  the  threat.  While  conducting  MIO  of  a 
target  of  interest,  the  SAG  is  confronted  with  a  threatening  swarm 
of  small  boats  emanating  from  BROWN’s  national  waters.  The 
SAG  must  continue  current  MIO  of  the  target  of  interest  while 
addressing  the  swann  of  small  boats. 

_ The  year  is  2020.  The  SAG  consists  of  1  CG,  1  PPG,  and  1  LCS. 

Actors  -  Systems  Officer  in  Tactical  Command  (OTC) 

&  Stakeholders 

Suspect  Vessel 
Support  Forces 
Swarm  Boats 
Sensor  System 

Common  Tactical  Picture  (CTP)  system 

_ Weapon  System _ 

Flow  of  events  1 .  ... 

2.  Sensor  system  reports  probable  surface  targets  and  location  to 
CTP  system  [a], 

3.  OTC  assigns  additional  sensor  systems  to  probable  surface 
targets  for  confirmation  [a]. 

4.  Data  from  sensor  system(s)  is  correlated  and  fused  to  determine 
probable  surface  targets  precise  location.  Sensor  System(s) 
report  precise  location  of  probable  surface  targets  to  CTP 
system  [a], 

5.  Sensor  system(s)  provide  confirmation  of  surface  targets  - 
swarm  boats  -  to  CTP  system  [a], 

6.  Sensor  system(s)  provide  swann  boats’  window  of  vulnerability 
to  CTP  system  [a]. 

7.  OTC  assigns  sensor  system(s)  to  continually  track  the  swann 
boats. 

8.  Sensor  system(s)  provide  refined  window  of  vulnerability  of 
swarm  boats  to  CTP  system  [a]. 

9.  OTC  validates  swarm  boats  comply  with  guidance,  LOAC, 
ROE,  and  other  restrictions  [a]. 

10.  OTC  determines  desired  effect(s)  against  swarm  boats  [a]. 

1 1 .  Potential  engagement  options  are  generated  through  weapon- 
target  pairings  (WTPs)  and  are  presented  to  OTC  [a], 

_ 12.  OTC  conducts  risk  assessment  of  engagement  options  [a], _ 
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13.  OTC  orders  swarm  boats  to  be  engaged  with  selected 
engagement  option  [a]. 

14.  Weapon  system  engages  swann  boats  [a]. 

15.  OTC  reviews  status  of  the  swann  boats  noted  in  Common 

Tactical  Picture  system  [a]. 

16.  OTC  assesses  status  of  the  swann  boats  and  detennines  whether 
to  re-engage  [a]. 

Inputs 

Rules  of  Engagement  (ROE) 

Law  of  Armed  Conflict  (LOAC) 

Probable  Target  Detection 

Probable  Target  Location 

Target  Confirmation 

Precise  Location  of  Confirmed  Target 

Confirmed  Target  Window  of  Vulnerability 

Refined  Window  of  Vulnerability  for  Confirmed  Target 

Engagement  Options 

Outputs 

Engagement  Order 

Re-engagement  Order 

References 

a.  JP  3-60:  Joint  Targeting  (2007) 

Table  18.  Scenario  CHARLIE  -  1 
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APPENDIX  B:  TARGET  ENGAGEMENT 


Several  target  engagement  process  models  have  been  developed  and  presented  in 
service  documents.  The  detect-to-engage  sequence  for  prosecuting  threats,  as  described 
by  Athans  [1986]  and  Payne  [2006],  is  a  model  used  for  the  training  of  future  officers  in 
the  U.S.  Navy.  Conversely,  the  Find-Fix-Track-Target-Engage-Assess  (F2T2EA) 
process  model  has  been  used  with  respect  to  time-sensitive  targeting  [Committee  on 
C4ISR  for  Future  Naval  Strike  Groups,  2006:  42;  Hunerwadel,  2006],  F2T2EA  has  been 
adopted  by  all  services  for  dynamic  and  time-sensitive  targeting  [JP  3-60,  2007]  at  the 
operational  level  of  war. 

Though  the  detect-to-engage  sequence,  F2T2EA,  and  the  general  targeting 
process  presented  in  JP  3-60  [2007]  are  all  similar,  differences  in  terminology  can 
confound  a  reader.  Therefore,  the  F2T2EA  engagement  process  model  and  associated 
tenninology  as  detailed  in  JP  3-60  [2007:  Ch  II],  was  selected  by  the  author  to  serve  as  a 
foundation  for  the  development  of  the  tactical  threat  and  target  engagement  scenarios. 
The  steps  of  F2T2EA  [JP  3-60,  2007]  are  explained  in  below  and  presented  in  Figure  38. 
and  Figure  39. 

FIND 

Input:  Inputs  to  the  find  step  are  clear  priorities  and  guidance  from  the  Joint 
Force  Commander,  intelligence  of  the  battlespace  to  include  areas  of  interest,  and 
intelligence,  surveillance,  and  reconnaissance  (ISR)  collection  plans. 

Phase:  The  intelligence  collection  process  is  the  primary  driver  of  the  find  step. 
Detections  which  meet  predetermined  criteria  are  deemed  emerging  targets.  An 
emerging  target’s  criticality,  time-sensitivity,  and  probability  of  being  a  target  is  further 
refined  in  the  find  phase.  Emerging  targets  which  are  considered  potential  targets  are 
moved  to  subsequent  steps.  Those  deemed  not  to  be  a  potential  target  are  dropped  from 
the  process.  If  it  is  not  known  whether  a  emerging  target  is  a  potential  target  or  not,  the 
detection  remains  in  the  find  step. 
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Output:  The  output  of  the  find  step  is  potential  targets  “detected  and  nominated 
for  further  development”  [JP  3-60,  2007:  Ch  II,  15]. 

FIX 

Input:  The  inputs  to  the  fix  step  include  potential  targets  from  the  find  step  and 
sensor  infonnation  on  the  target. 

Phase:  In  the  fix  step,  the  identification  of  potential  targets  is  confirmed  and  the 
target’s  precise  location  is  determined  through  means  of  data  correlation  and  fusion. 

Also  during  the  fix  step,  the  target’s  window  of  vulnerability  is  established  for 
prosecution  and  prioritization. 

Output:  The  output  of  the  fix  step  is  the  identification,  classification,  and 
confirmation  of  the  target,  the  location  of  the  target  accurate  enough  for  target 
engagement,  and  the  target  window  of  vulnerability. 

TRACK 

Input:  Inputs  to  the  track  step  are  a  confirmed  target  with  location  accurate 
enough  for  target  engagement. 

Phase:  In  the  track  step,  sensors  are  selected  to  continually  track  the  confirmed 
target.  The  sensors  are  selected  according  to  prosecution  needs  and  prioritization  based 
on  all  targets’  window  of  vulnerability.  The  targets’  window  of  vulnerability  is  further 
refined  by  the  data  collected  from  the  assigned  sensors. 

Output:  The  output  of  the  track  step  is  a  continuous  track  of  the  confirmed 
target,  the  sensor  prioritization  scheme,  and  updated  target  window  of  vulnerability. 

TARGET 

Input:  The  inputs  for  the  target  step  include: 

1 .  Identified,  classified,  located,  and  prioritized  target 

2.  Collateral  damage  guidance 

3.  Rules  of  Engagement  (ROE) 


122 


4.  Law  of  Armed  Conflict  (LOAC) 

5.  No-strike  List  (NSL) 

6.  Restricted  Target  List  (RTL) 

7.  Fire  Support  Coordinating  Measures  (FSCMs) 

8.  Situational  awareness  (SA)  on  available  assets 

Phase:  The  target  step  begins  with  validating  the  confirmed  target  complies  with 
guidance,  LOAC,  ROE,  and  other  restrictions.  The  desired  effect  against  the  confirmed 
target  is  finalized,  restrictions  are  resolved,  and  risk  assessment  is  performed.  De- 
confliction  of  sensors  and  weapon  systems  enables  weapon-target  pairings  (WTPs)  and 
generation  of  potential  engagement  option.  Once  the  target  approval  decision  is  made,  an 
engagement  option  is  selected.  Assessment  requirements  are  determined  and  the 
consequences  of  executing  the  engagement  option  are  also  predicted. 

Output:  The  outputs  of  the  target  step  include  the  validated  desired  effect,  target 
data  finalized  in  a  fonnat  for  use  by  the  engaging  system,  asset  deconfliction  and 
resolved  target  area  clearance,  and  target  execution  approval,  assessment  collection 
requirements,  and  consequences  of  execution. 

ENGAGE 

Input:  Inputs  to  the  engage  step  are  the  target  approval  decision,  the  selected 
engagement  option,  and  the  finalized  data  of  the  confirmed  target. 

Phase:  During  the  engage  step,  engagement  of  the  confirmed  target  is  ordered 
and  passed  to  the  selected  weapon  system(s). 

Output:  The  output  of  the  engage  step  is  the  engagement  of  the  confirmed  target. 
ASSESS 

Input:  The  inputs  to  the  assess  phase  are  the  combat  assessment  requirements, 
the  validated  desired  effect,  and  the  prediction  of  the  consequences  of  execution. 

Phase:  During  the  assess  phase  information  concerning  the  infonnation  is 
collected  in  accordance  with  the  combat  assessment  requirements.  The  infonnation  is 
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used  to  estimate  or  confirm  whether  the  results  of  the  engagement  match  the  desired 
effect(s).  Information  is  also  collected  to  detennine  if  any  consequences  of  the 
engagement  require  warning  friendly  forces. 

Output:  Outputs  of  the  assess  phase  are  engagement  results;  re-attack  (re-strike) 
recommendations,  as  appropriate;  and  any  warnings  to  friendly  forces  based  on 
engagement  results. 
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Figure  38.  Dynamic  Targeting  Process  [from  JP  3-60,  2007:  Ch  II,  14] 
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Figure  39.  Dynamic  Targeting  Process  -  IDEFO 
[after  JP  3-60,  2007:  Ch  II,  14] 
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APPENDIX  C:  EXTERNAL  SYSTEMS  DIAGRAM 


The  discussions  within  this  appendix  are  divided  into  four  sections.  The  first 
section  is  devoted  to  discussing  the  challenge  in  developing  the  basic  external  systems 
diagram.  The  second  section  presents  the  basic  external  systems  diagram  and  the  reasons 
behind  key  contents  of  the  diagram.  The  third  section  is  a  collection  of  the  interaction 
diagrams  developed  during  research.  Finally,  the  fourth  section  is  a  presentation  of  the 
external  systems  diagram. 

A.  THE  PHILOSOPHICAL  CHALLENGE 

Recall  from  the  body  of  the  thesis  that  the  basic  external  systems  diagram  is 
comprised  of  three  parts:  the  system,  the  external  systems,  and  the  system  context.  The 
system  is  "a  set  of  components  (subsystems,  segments)  acting  together  to  achieve  a  set  of 
common  objectives  via  the  accomplishment  of  a  set  of  tasks"  [Buede,  2000:  38]. 

External  Systems  are  "entities  that  interact  with  the  system  via  the  system's  external 
interfaces"  [Buede,  2000:  38].  Finally,  the  context  is  "a  set  of  entities  that  can  impact  the 
system  but  cannot  be  impacted  by  the  system"  [Buede,  2000:  38]. 

Since  the  purpose  of  the  external  systems  diagram,  and  therefore  the  basic 
external  systems  diagram,  is  to  define  the  boundaries  of  the  system  for  all  stakeholders  of 
the  system,  the  author  was  faced  with  the  question  of  “What  comprises  a  C2  system?” 
This  question  is  critical  in  the  development  of  the  operational  concept.  The  question  also 
exemplifies  how  the  key  phases  of  the  operational  concept  development  (e.g.,  scenario 
development,  external  systems  diagram,  systems  objective  hierarchy,  and  requirements 
generation)  are  intertwined. 

Describing  the  inputs  and  outputs  in  the  scenario  development  demonstrates  the 
stakeholders’  and  systems  engineers’  preconceived  notions  of  the  system’s  boundaries. 
Additionally,  as  the  stakeholders  and  systems  engineers  communicate  concerning  the 
“value”  of  the  system  during  the  system  objective  hierarchy  development,  the  common 
view  of  the  system’s  boundaries  may  change.  Each  phase  of  the  operational  concept 
development  serves  as  feedback  to  previous  phases.  With  sufficient  iterations  and 
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communication,  the  systems  engineers  can  eventually  reach  a  stable  (though  not 
necessarily  constant)  view  of  the  system.  For  example,  during  the  communication 
deriving  the  “value”  of  the  system  in  the  system  objective  hierarchy  certain  subsystems 
became  viewed  as  external  systems  and  vice  versa  in  a  new  version  of  the  external 
systems  diagram.  This  reorganization  of  components  then  drove  the  scenarios  and 
interaction  diagrams  to  be  redrafted  since  the  inputs  and  outputs  of  the  system  changed. 
But,  the  question  still  remains,  “What  comprises  a  C2  system?” 

To  answer  this  question  the  author  conducted  an  extensive,  but  by  no  means 
exhaustive,  literature  review.  Historical  texts,  recent  articles  and  books,  and  service 
publications  were  read  and  analyzed.  Much  of  the  historical  texts  contained  discussions 
on  war  and  its  principles  as  well  as  theories  and  methodologies  of  conducting  warfare. 

The  texts,  however,  contained  limited  content  devoted  specifically  to  topics  correlating  to 
the  modern  concept  command  and  control.  Significant  research  concerning  the  principles 
of  command  and  control  only  began  within  the  past  half-century.  Much  of  this  early 
work  on  a  theory  of  command  and  control  was  based  on  models  of  the  C2  process  such  as 
Lawson’s  [1981]  Sense-Process-Compare-Decide-Act  model  or  Boyd’s  Observe-Orient- 
Decide-Act  model.  To  start  the  definition  of  a  C2  system  with  a  C2  process,  whether 
adopted  or  modified  from  previous  researchers  or  developed  separately,  may  seem  logical 
but  contains  consequences. 

Recall  that  a  system  is  “a  set  of  components  (subsystems,  segments)  acting 
together  to  achieve  a  set  of  common  objectives  via  the  accomplishment  of  a  set  of  tasks” 
[Buede,  2000:  38],  A  system,  therefore,  is  defined  by  1)  its  set  of  objectives  and  2)  the 
tasks  required  to  achieve  such  set  of  objectives.  The  execution  of  the  C2  process 
becomes  the  objective  of  a  C2  system  and  the  tasks  required  to  achieve  this  objective  are 
at  least  the  phases  of  the  C2  process.  For  example,  the  tasks  required  to  achieve  the 
objective  in  Lawson’s  model  are  at  least  to  sense,  process,  compare,  decide,  and  act. 

Continuing  the  Lawson  model  example,  since  one  task  of  the  C2  system  would  be 

to  decide,  a  component  or  a  combination  of  components  of  the  C2  system  must  fulfill  this 

task.  Therefore,  the  decision  entity  -  which  in  most  military  situations  is  the  commander 

-  is  a  component  of  the  system.  Similarly  the  sensor  which  senses  should  be  considered 
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a  component  of  the  system.  Then  should  the  entity  which  acts  also  be  considered  a 
component?  If  so,  then  the  entire  military  force  involved  in  a  situation  is  the  C2  system. 
The  C2  systems  engineer  is  then  faced  with  designing  the  best  military  force  for  a  given 
set  of  situations,  which  incidentally  is  the  responsibility  of  senior  military  leadership.  Of 
course  a  commander-in-chief  can  view  himself  or  herself  as  a  systems  engineer  but,  a 
subsystem  within  a  military  force  with  the  objective  of  accomplishing  the  C2  process 
would  then  not  exist. 

The  next  logical  step  would  then  be  to  consider  reversing  the  previous  step  and 
remove  those  entities  which  act  from  the  concept  of  the  C2  system  definition.  In  other 
words,  the  C2  system’s  purpose  would  remain  the  accomplishment  of  the  C2  process  but, 
the  task  of  acting  would  be  fulfilled  by  a  system  external  to  the  C2  system.  Similarly 
those  sensors  which  sense,  and  those  decision-making  entities  which  decide,  could  be 
removed  from  the  concept  of  a  C2  system  for  the  same  reason  and  their  tasks  could  be 
fulfilled  by  external  systems.  Continuing  this  process  generates  a  C2  system  with  the 
task  of  connecting  the  tasks  (i.e.,  sense,  process,  compare,  decide,  and  act)  of  the  external 
systems.  A  C2  system,  therefore,  is  at  least  a  communication  system  (a  system  which 
connects)  and  at  most  the  entire  military  force. 

As  is  evident  in  the  above  discussion,  the  definition  of  a  C2  system  has  now 
become  detached  from  the  C2  process.  The  system  is  at  least  comprised  of  components 
which  connect  but  may  or  may  not  include  those  components  which  perform  the  tasks 
associated  with  the  C2  process.  This  logical  discussion  has  achieved  a  lower  bound  to 
the  question,  “What  comprises  a  C2  system?”  It,  however,  has  not  achieved  a  realistic 
upper  bound.  An  astute  reader  may  have,  at  this  point,  realized  that  the  entire  discussion 
above  for  determining  the  boundaries  of  the  C2  system  progressed  through  the  tasks  (or 
functions)  of  the  system.  How  can  this  be?  The  operational  concept  is  supposed  to  be  an 
input  to  the  functional  architecture.  The  reader  is  then  plagued  by  the  philosophical 
question  of  “How  does  one  define  the  boundaries  of  a  system  in  ignorance  of  what  the 
system  does?”  The  fact  of  the  matter  is  one  does  not. 

What,  then,  comprises  a  C2  system?  The  answer  to  the  question  is  confusingly 

simple  -  what  the  systems  engineer  and  stakeholders  determine.  As  systems  engineers 
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communicate  with  stakeholders,  as  stakeholders  are  added  and  dropped,  and  as  the 
system  engineering  process  is  followed  from  the  birth  to  the  death  of  the  system,  the 
definition  of  what  the  system  is  changes.  Therefore,  the  basic  external  systems  diagram 
below,  and  the  subsequent  work  of  this  thesis,  presents  a  C2  system  from  the  view  of  the 
author  and  those  solicited  stakeholders  whom  interacted  with  the  author.  It  is  by  no 
means  a  definitive  solution.  As  readers  join  the  study  and  analysis  of  C2,  the  definition 
of  what  a  C2  system  is  will  invariably  change. 

B.  BASIC  EXTERNAL  SYSTEMS  DIAGRAM 

The  basic  external  systems  diagram  developed,  as  of  the  submittal  of  this  thesis,  is 
presented  in  Figure  40.  Also  presented  in  this  section  are  key  thoughts  of  the  author  and 
ideas  gleaned  from  the  author’s  communication  with  stakeholders.  Though  by  no  means 
comprehensive,  the  author  has  attempted  to  address  the  major  concerns  of  potential 
readers. 

As  in  discussed  in  Chapter  II,  the  author  adopted  the  concept  of  function-process- 
system  for  command  and  control.  First,  command  is  a  function  by  which  a  responsible 
entity  takes  inputs  to  produce  the  desired  output.  Second,  command  and  control  is  the 
process  by  which  the  inputs  generate  the  outputs.  Finally,  a  command  and  control  system 
is  the  means  by  which  the  process  is  executed.  This  function-process-system  concept  is 
similar  to  that  presented  by  Sweeney  [2002]  but,  with  at  least  one  major  modification. 
Sweeney  posits  that  the  command  and  control  process  is  comprised  of  people, 
information,  and  organization.  The  author,  instead,  posits  that  people  are  a  component  of 
the  command  and  control  system,  information  is  what  flows  within  the  system,  and 
organization  is  a  rule  or  constraint  on  the  system.  This  version  of  the  concept 
incorporates  ideas  of  Van  Creveld  [1985],  the  U.S.  Marine  Corps  [MCDP  6,  1996],  and 
the  U.S.  Navy  [NDP  6,  1995]  among  many.  This  can  be  seen  with  the  two  major 
subsystem  categories  in  Figure  40.  ,  People  and  the  Communications  &  Information 
Systems.  The  inputs  to  and  outputs  from  the  system,  along  with  the  cross-communication 
between  subsystems,  are  Information. 
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CONTEXT 


Figure  40.  Basic  External  Systems  Diagram 

The  commander,  in  this  case  the  OTC,  is  not  considered  a  part  of  the  command 
and  control  system.  Since  the  command  and  control  system  is  the  means  by  which  the 
command  and  control  process  executes  the  function  of  command  for  the  commander,  the 
commander  is  not  a  component  of  system.  The  commander  is  an  external  system  which 
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affects  the  command  and  control  process  and  interacts  with  the  command  and  control 
system.  If  during  the  command  and  control  process  a  decision  by  the  commander  is 
needed,  such  decision  is  an  input  to  the  command  and  control  system. 

Sensors,  weapons,  and  platforms  are  considered  external  systems.  These  external 
systems  provide  inputs  such  as  their  geographical  position,  readiness,  and  in  the  case  of 
sensors  information  concerning  contacts,  targets,  threats,  and  the  adversary.  During  the 
command  and  control  process  a  sensation  by  a  sensor  is  needed,  such  sensation  is  an 
input  to  the  command  and  control  system.  Similarly,  during  the  command  and  control 
process  an  action  by  a  weapon  or  platform  is  needed,  the  order  for  the  action  is  an  output 
from  the  system  to  the  weapon  or  platform.  Additionally,  contacts,  targets,  threats,  and 
the  adversary  interact  with  external  systems  such  as  sensors  and  weapons,  which  then 
report  to  the  command  and  control  system  information  of  such  interaction.  Other  context 
entities  produce  inputs  to  the  system  but  are  not  affected  by  the  command  and  control 
system,  at  least  in  the  time-frame  considered  for  this  thesis.  Such  context  entities  include 
meteorological  factors,  the  political  situation,  and  the  international  legal  system. 

C.  INTERACTION  DIAGRAMS 

Below  is  a  collection  of  interaction  diagrams  developed  in  support  of  the  external 
systems  diagram. 
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-Re-engagement  Order- 
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Figure  4 1 .  Interaction  Diagram  -Contact  Prosecution 
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Figure  42.  Interaction  Diagram  -  Legal  Constraints 


Figure  43.  Interaction  Diagram  -  Information  and  Intelligence  Requests 


D.  EXTERNAL  SYSTEMS  DIAGRAM 

The  external  systems  diagram  expands  the  basic  external  systems  diagram  to 
include  the  inputs  and  outputs  detailed  in  interaction  diagrams.  The  purpose  of  the 
external  systems  diagram  is  to  model  the  “interaction  of  the  system  with  other  (external) 
systems  in  the  relevant  contexts,  thus  providing  a  definition  of  the  system’s  boundaries  in 
terms  of  the  system’s  inputs  and  outputs”  [Buede,  2000:  144].  The  external  systems 
diagram  is  shown  in  Figure  44. 
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Figure  44.  External  Systems  Diagram 
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APPENDIX  D:  SYSTEM  OBJECTIVES  HIERARCHY 


The  purpose  of  the  systems  objectives  hierarchy  is  to  organize  the  system’s 
objectives  from  the  view  of  value  to  the  stakeholders  [Buede,  2000:  147].  Objectives 
exist  in  every  phase  of  the  system’s  life-cycle.  Types  of  objectives  can  include 
operational  perfonnance  objectives,  technical  performance  objectives,  operational 
suitability  objectives,  cost  objectives,  schedule  objectives,  and  risk  objectives.  The 
discussions  within  this  appendix  are  divided  into  three  sections.  The  first  section  is 
devoted  to  discussing  the  process  of  developing  the  system  objectives  hierarchy.  The 
second  section  presents  the  system  objectives.  Finally,  the  third  section  presents  the 
selected  measures  of  merit. 

A.  SYSTEM  OBJECTIVES  DEVELOPMENT 

The  purpose  of  the  system  engineering  process  is  to  design  and  develop  a  system 
which  takes  inputs  to  produce  desired  outputs  or  to  avoid  undesirable  consequence.  The 
entire  notion  of  desirability  is  one  of  value  [Keeney,  1992].  The  purpose  of  system 
objectives  is  to  explicitly  describe  the  value  of  the  system  as  detennined  by  the  system’s 
stakeholders.  The  top-level  of  the  hierarchy  of  objectives  are  fundamental  objectives 
which  describe  the  values  of  the  system  which  are  essential.  The  fundamental  objectives 
are  composed  of  subordinate  objectives  which  serve  as  measures  of  merit  of  the  system. 

The  system  objective  development  process  began  with  the  refined  problem 
statement,  developed  during  scenario  development,  serving  as  a  guide.  Keeney  [1992: 
56]  proposes  that  “The  most  obvious  way  to  identify  objectives  is  to  engage  in  a 
discussion  of  the  decision  situation.”  Since  publication  research  is  a  form  of  discussion, 
as  Booth,  Colomb  and  Williams  contend  [2008:  1 1],  numerous  publications  concerning 
measures  of  effectiveness,  operational  suitability,  C4ISR  system  capabilities, 
communications,  information  theory,  and  network-centric  warfare  were  reviewed  to 
determine  qualities  pertinent  to  a  network-centric  naval  tactical  command  and  control 
system.  In  conjunction  with  the  publication  review,  inputs  from  stakeholders  were 
solicited  to  assist  the  author  developing  and  organizing  the  system’s  objectives  and  their 
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associated  measures  of  merit  (i.e.,  measures  of  effectiveness  and  their  associated 
measures  of  performance)  [Buede,  2000:  146-149].  Objective  development  during  the 
early  stages  of  the  systems  engineering  process  is  important.  By  developing  a  set  of 
system  objectives  prior  to  the  functional  architecture  and  physical  architecture 
development  phases,  the  system  engineer  identifies  the  value  of  the  system  outside  the 
constraints  of  any  particular  design.  The  reader  is  encouraged  to  review  Keeney  [1992] 
for  more  discussion  on  this  topic. 

Reviewing  a  variety  of  publications,  and  with  stakeholder  input,  the  author 
determined  there  were  six  fundamental  objectives:  quality  of  information;  quality  of 
relationships/connections;  awareness  of  established  intent;  awareness  of  rules  and 
constraints;  quality  of  response;  and  quality  of  allocations.  The  first  four  fundamental 
objectives,  together,  address  the  concept  the  quality  of  situational  awareness.  Likewise, 
the  last  two  fundamental  objectives,  together,  address  the  concept  of  quality  of  response. 
The  top-level  of  the  system  objectives  hierarchy,  which  is  comprised  of  the  fundamental 
objectives  (FO)  and  the  measures  of  C2  effectiveness  (MoCE),  is  presented  in  Figure  45. 

Each  of  the  fundamental  objectives  is  an  aggregation  of  several  measures  of  merit 
(MoM)  [NATO  Research  and  Technology  Organization,  2002]  collected  from  and 
developed  during  the  publication  review  and  stakeholder  solicitation.  Since  the  focus  of 
this  thesis  was  on  naval  tactical  forces  tasked  with  securing  local  sea  control,  Measures  of 
Policy  Effectiveness  (MoPE),  were  not  considered.  Additionally,  Measures  of  Force 
Effectiveness  (MoFE)  were  not  considered  since  mission  accomplishment  is  not  a 
measure  of  the  C2  system  but  rather  the  force.  The  removal  of  mission  accomplishment 
from  the  quality  measure  of  a  C2  system  is  an  idea  further  discussed  by  Alberts  and 
Hayes  [2006:  Chapter  4]. 

The  MoM  levels  considered  for  this  thesis  included  Measures  of  C2  Effectiveness 
(MoCE),  Measures  of  Performance  (MoP),  and  Dimensional  Parameters  (DP).  MoCE 
focus  on  the  impact  of  C2  systems  within  the  operational  context.  MoP  measure  the 
performance  within  the  system  structure.  Finally,  the  lowest  level,  Dimensional 
Parameters  (DP),  measure  the  properties  or  characteristics  inherent  in  the  physical  parts 
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and  configuration  items  of  the  C2  systems.  It  is  a  general  rule  that  a  measure  higher  in 
the  MoM  hierarchy  tends  to  be  more  context,  task,  or  mission  specific  [NATO  Research 
and  Technology  Organization,  2002:  96]. 

A  responsive  and  robust  command  and  control  system  which 
connects  dispersed  forces  and  enables  such  forces  to  self- 
synchronize  and  allocate  resources  to  mass  effects  in  order  to  meet 
the  established  intent  at  the  tactical  level  of  war. 


Figure  45.  System  Objectives  Hierarchy 

To  ensure  the  system  objectives  hierarchy  did  not  become  an  ad  hoc  collection  of 
objectives  and  measures  gleaned  from  various  sources,  the  nine  desirable  attributes  of 
fundamental  objectives  presented  by  Keeney  [1992:  82-87]  were  used  as  a  guide  during 
development.  The  descriptions  of  the  nine  attributes  were  adapted  to  the  system 
engineering  process,  as  described  below,  and  were  adopted  whenever  possible  for  this 
thesis.  First,  the  fundamental  objectives  of  the  system  should  be  essential  to  the  design 
of  the  command  and  control  system;  each  alternative  design  of  the  command  and  control 
system  impacts  the  degree  to  which  the  fundamental  objectives  are  achieved.  Second,  the 
fundamental  objectives  of  the  system  should  be  controllable ;  the  fundamental  objectives 
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are  impacted  only  by  the  alternative  designs  of  the  command  and  control  system.  Third, 
the  set  of  fundamental  objectives  of  the  system  should  be  complete;  the  alternative 
designs  of  the  system  can  be  differentiated  from  each  other  by  the  set  of  fundamental 
objectives.  Fourth,  the  fundamental  objectives  of  the  system  should  be  measurable ;  each 
of  the  fundamental  objectives,  and  the  degree  to  which  they  can  be  achieved,  can  be 
precisely  defined.  Fifth,  the  fundamental  objectives  should  be  operational,  information 
can  be  collected  which  link  the  various  levels  of  the  fundamental  objectives  to  value  of 
the  system.  Sixth,  the  set  of  fundamental  objectives  of  the  system  should  be 
decomposable ;  the  impact  of  one  fundamental  objective  can  be  considered  independently 
of  another  fundamental  objective.  Seventh,  the  fundamental  objectives  of  the  system 
should  be  non-redundant.  Eighth,  the  set  of  fundamental  objectives  of  the  system  should 
be  concise.  Conciseness  conflicts  with  the  attribute  of  completeness,  however,  by 
eliminating  objectives  which  provide  little  assistance  in  comparing  alternative  systems 
the  decision  scope  is  reduced.  Ninth,  each  of  the  fundamental  objectives  must  be 
understandable ;  the  idea  of  each  fundamental  objective  can  be  “adequately 
communicated  to  and  understood  by  individuals  in  positions  to  make  or  influence 
decisions”  [Keeney,  1992:  85]. 


Attributes  of  Fundamental  Objectives 

Essential 

Controllable 

Complete 

Measurable 

Operational 

Decomposable 

Non-redundant 

Concise 

Understandable 

Table  19.  Attributes  of  Fundamental  Objectives  [Keeney,  1992] 


The  first  step  to  ensuring  the  set  of  fundamental  objectives  were  essential  was  to 
review  the  previous  products  of  the  operational  concept.  As  discussed  in  Appendix  C: 

External  Systems  Diagram  the  C2  system  contains  communication  and 
information  systems  which  connect  nodes  and  information  flows  through  these 
connections.  Therefore,  quality  of  information  and  quality  of  relationships  and 
connections  are  essential.  Quality  of  relationships  and  connections  was  also  essen  tial 
because  of  the  portion  of  the  refined  problem  statement;  “command  and  control  system 
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which  connects  dispersed  forces.”  The  refined  problem  statement  also  states  the  C2 
system  should  enable  forces  to  “allocate  resources. . .  in  order  to  meet  established 
intent....”  Therefore,  awareness  of  established  intent  and  quality  of  allocations  are  also 
essential.  Recall,  as  discussed  in  Chapter  II,  that  a  C2  system  is  the  means  by  which  the 
C2  process  is  executed.  Therefore,  the  third  step  to  ensure  the  set  of  fundamental 
objectives  were  essential  was  to  review  several  conceptual  models  of  the  C2  process. 
Conceptual  models  reviewed  included  Lawson  [1981],  Athans  [1986],  Levis  and  Athans 
[1992],  Alberts  and  Hayes  [2006],  as  well  as  those  presented  in  NDP  6  [1995]  and  JP  3- 
60  [2007].  Though  these  conceptual  models  are  “abstractions  and  idealizations”  [Levis 
&  Athans,  1992:  6],  they  do  provide  examples  of  what  C2  systems  are  expected  to 
support.  All  of  the  conceptual  models  reviewed  describe  a  phase  of  the  C2  process 
consists  of  a  decision  or  decision-making.  Therefore,  quality  of  response  decision  is  also 
an  essential  objective.  In  addition,  all  of  the  conceptual  models  reviewed  describe  a 
phase  of  the  C2  process  which  consists  of  actions  of  forces  or  directions  to  forces  to  act. 
Since  these  forces  act  within  an  environment  and  are  subject  to  rules  and  constraints, 
whether  self-imposed  or  imposed  by  higher  authority,  awareness  of  rules  and  constraints 
is  also  an  essential  objective.  The  discussion  above  has  demonstrated  that  each  of  the  six 
fundamental  objectives  is  essential  to  the  design  of  a  C2  system.  The  next  step  is  to 
determine  if  the  set  of  fundamental  objectives  is  complete. 

A  C2  system  is  the  means  by  which  the  C2  process  is  executed.  Therefore,  every 
phase  of  the  C2  process  should  either  have  a  corresponding  objective  or  it  should  be 
explicitly  stated  why  it  does  not.  Several  C2  process  conceptual  models  will  be  used  to 
determine  if  the  set  of  fundamental  objectives  are  complete.  Lawson  [1981]  presents  a 
model  simplified  as  sense-process-compare-decide-act.  Levis  and  Athans  [1992]  present 
a  similar  model  simplified  as  sense-assess-generate-select-plan-direct.  In  the  external 
systems  diagram,  sensors  are  considered  external  systems  which  provide  information  to 
the  C2  system.  Therefore,  quality  of  information  corresponds  to  the  concept  of  sense. 
Some  of  the  MoM  of  quality  of  information  correspond  to  process  and  assess  (i.e.,  the 
concepts  of  accuracy,  usability,  completeness,  and  precision  allude  to  a  form  of 
assessment  of  processed  data).  In  addition,  awareness  of  established  intent  and 
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awareness  of  rules  and  constraints  incorporate  portions  of  assess.  Some  of  the  MoM  of 
quality  of  response  decision  and  quality  of  allocations  correspond  to  generate  (e.g., 
response  solution  space)  and  select  (e.g.,  appropriateness  of  response  decision).  In 
addition,  the  concepts  of  decide  and  plan  are  also  incorporated  in  these  two  fundamental 
objectives.  Sensors,  weapons,  and  platfonns  are  external  systems  which  receive 
information  from  the  C2  system.  Therefore,  quality  of  information  corresponds  to  the 
concepts  of  direct  and  act. 

The  models  presented  by  Athans  [1986]  and  in  JP  3-60  [2007]  are  specific  to 
target  engagement  and  discussed  in  Appendix  B:  Target  Engagement.  In  fact,  the 
models  presented  by  Athans  and  in  JP  3-60  are  so  specific,  and  the  concepts  within  the 
objectives  hierarchy  so  general  (e.g.,  response,  allocation,  etc.)  that  it  is  difficult  to 
determine  if  the  objectives  hierarchy  does  not  incorporate  all  of  the  concepts  of  these 
models.  A  review  of  Appendix  B:  Target  Engagement  identified  only  a  few  concepts 
not  already  obviously  addressed  with  the  Lawson  model  and  Levis  and  Athans  model 
analysis  above.  These  concepts  include  prioritizing  ISR,  tracking,  target  area  clearance, 
and  risk  assessment.  Prioritizing  ISR  is  a  decision  to  allocate  of  resources.  Quality  of 
response  decision  and  quality  of  allocations,  therefore,  correspond  to  prioritizing  ISR. 
Tracking  is  continuous  sensing,  processing,  and  assessing.  Thus,  as  discussed  above, 
some  of  the  MoM  of  quality  of  information  correspond  to  tracking.  Target  area  clearance 
is  directing  friendly  forces  to  vacate  a  specific  area  for  their  safety.  Therefore,  the 
allocation  of  roles  and  responsibilities  addresses  target  area  clearance.  Finally,  risk 
assessment  corresponds  to  appropriateness  of  response  decision.  The  discussion  in  the 
previous  paragraphs  has  demonstrated  that  the  set  of  fundamental  objectives  is,  to  an 
arguable  extent,  complete.  Given  that  there  are  only  six  fundamental  objectives,  the 
author  contends  that  the  set  is  also  concise. 

The  fundamental  objectives  are  measureable  in  the  fact  that  they  are  aggregations 
of  several  MoM  collected  from  and  developed  during  the  publication  review  and 
stakeholder  solicitation.  Defoe  [1993]  states,  “Select  criteria  that  are  measurable 
(objective  and  quantifiable)  and  express  them  in  well-known,  easily  understood  units. 
However,  important  criteria  for  which  no  measure  seems  to  exist,  still  must  be  explicitly 
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addressed.”  The  set  of  fundamental  objectives  is  essential  and  complete',  following 
Defoe’s  principle  of  measurability,  no  fundamental  objective  was  removed  if  their 
associated  MoM  are  difficult  to  measure.  In  fact  those  objectives  which  are  difficult  to 
measure  align  with  the  moral  factors  of  command  and  control,  as  discussed  in  Chapter  II. 
Overview  of  Command  and  Control 

In  addition  to  the  attributes  previously  discussed,  the  fundamental  objectives 
should  also  be  operational.  In  other  words,  information  should  exist  which  proves  the 
fundamental  objectives  give  value  to  the  system.  Validating  each  fundamental  objective 
and  its  associated  MoM  with  extensive  testing,  analysis,  or  research,  was  beyond  the 
scope  of  this  thesis.  The  validity  of  the  fundamental  objectives,  therefore,  is  detennined 
by  the  fact  that  most  were  identified  in  other  publications  concerning  C2  or  were  in  fact 
specifically  referenced  in  previous  C2  research.  Next,  given  that  the  author  cannot 
guarantee  that  the  system  objectives  are  understandable,  stakeholders  were  solicited 
during  the  development  to  mitigate  future  problems  of  misunderstanding.  Finally,  it  is 
left  to  the  reader  to  analyze  the  system  objective  hierarchy  in  the  next  section  to  conclude 
for  themselves  whether  the  systems  objectives  are  decomposable  (e.g.,  independent)  and 
non-redundant. 

B.  SYSTEMS  OBJECTIVES  HIERARCHY 

The  system  objectives  hierarchy,  with  measures  of  merit,  developed  during  this 
thesis  for  a  command  and  control  system  is  presented  below  in  Table  20. 


QUALITY  OF  SITUATIONAL  AWARENESS 

1.0 

FO 

Quality  of  Information 

1.1. 

MoCE 

Relevance  of  information 

Clark  &  Moon,  2000 

JP  6-0,  2006:  Ch  1,  3 

NDP  6,  1995:  40 

1.1.1 

MoP 

Percentage  of  processed  information  needed  by 
nodes  for  response  to  changing  circumstances 

1.1.2 

MoP 

Percentage  of  information  a  node  receives  which  is 
a  copy  of  information  the  node  has  already  received 

1.1.3 

MoP 

Percentage  of  information  within  the  network 
which  is  a  copy  of  other  information  within  the 
network 

1.2 

MoCE 

Accuracy  of  information 

JP  6-0,  2006:  Ch  I,  3 

NDP  6,  1995:  40 
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1.2.1 

MoP 

Number  of  sources  confirming  information 

Clark  &  Moon,  2000:  Section  6 

1.2.2 

MoP 

Veracity  (i.e.,  truthfulness)  of  sources 

Clark  &  Moon,  2000:  Section  6 

1.2.2. 1 

DP 

History  of  truthfulness  of  specific  source 

2222 

DP 

Probability  specific  source  is  telling  the  truth 
concerning  selected  piece  of  information 

1.2.3 

MoP 

Equivocality  of  information  (i.e.,  degree  to  which 
data  is  subject  to  two  or  more  interpretations) 

1.2.3. 1 

MoP 

Number  of  possible  interpretations  of  data 

1.2. 3. 2 

MoP 

Probability  interpretation  of  data  is  correct 

1.2.4 

MoP 

Internal  consistency  of  information 

Clark  &  Moon,  2000:  Section  6 

1.2.4. 1 

MoP 

Percentage  of  total  information  held  which 
conflicts  with  other  information  held 

Clark  &  Moon,  2000:  Section  6 

1.2. 4. 2 

MoP 

Mean  time  between  internal  inconsistencies  of 
information  held 

1.3 

MoCE 

Timeliness  of  information 

Cebrowski  &  Garstka,  1998 

Clark  &  Moon,  2000 

JP  6-0,  2006:  Ch  I,  3 

NDP  6,  1995:  40 

Stytz  &  Banks,  2006 

1.3.1 

MoP 

Time  between  changing  circumstances  and 
observation 

after  Alberts  &  Hayes,  2006:  43 
after  Kasunic  &  Anderson, 

2004: 39 

1.3.2 

MoP 

Time  between  the  observation  and  the  completion 
of  processing  the  data  into  information 

after  Kasunic  &  Anderson, 

2004: 39 

1.3.3 

MoP 

Frequency  (i.e.,  refresh-rate)  of  information 

Clark  &  Moon,  2000:  Section  6 

1.3.3. 1.1 

MoP 

Minimum  time  specific  piece  of  information  is 
updated 

1.3.3. 1.2 

MoP 

Mean  time  specific  piece  of  information  is  updated 

1.3.3. 1.3 

MoP 

Median  time  specific  piece  of  information  is 
updated 

1.3.3. 1.4 

MoP 

Maximum  time  specific  piece  of  information  is 
updated 

1.3.4 

MoP 

Perishability  (i.e.  shelf-life)  of  information 

Clark  &  Moon,  2000:  Section  6 

1.3.4. 1 

DP 

Shelf-life  of  specific  information 

1.3. 4. 2 

MoP 

Difference  between  shelf-life  and  minimum  time 
specific  information  is  updated 

1.3. 4. 3 

MoP 

Difference  between  shelf-life  and  maximum  time 
specific  information  is  updated 

1.3. 4. 4 

MoP 

Probability  of  shelf-life  is  less  then  time  between 
updates 

1.3.5 

MoP 

Differential  between  time  when  information  is 
needed  by  a  particular  force  and  time  when  it 
arrives  at  that  force 

Stytz  &  Banks,  2006 

1.4 

MoCE 

Usability  of  information 

JP  6-0,  2006:  Ch  I,  3 

NDP  6,  1995:  40 

1.4.1 

MoP 

Latency  (i.e.,  visibility)  of  information 

Clark  &  Moon,  2000:  Section  6 

1.4.1. 1 

MoP 

Number  of  nodes  which  are  capable  of  viewing 
information 

1.4. 1.2 

MoP 

Percentage  of  nodes  which  are  capable  of  viewing 
information 

1.4. 1.3 

MoP 

Percentage  of  nodes,  which  are  capable  of  using 
information,  that  can  view  the  information 
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1.4.2 

MoP 

Shareability  of  information  (i.e.,  ability  of 
information  to  be  used  by  multiple  nodes) 

NATO  Research  and 

Technology  Organization 
(R&TO),  2006:  21 

1.4. 2.1 

MoP 

Percentage  of  nodes  authorized  to  act  upon 
information 

after  Washburn,  2001a:  6 

1. 4.2.2 

MoP 

Percentage  of  nodes  which  are  capable  of  acting  on 
information 

1.5 

MoCE 

Completeness  of  information 

Clark  &  Moon,  2000 

JP  6-0,  2006:  Ch  I,  3 

NDP  6,  1995:  40 

1.5.1 

MoP 

Range  (i.e.,  scale)  of  observation  capability 

1.5. 1.1 

DP 

Spatial  range  of  observation  capability 

1.5. 1.2 

DP 

Temporal  range  of  observation  capability 

1.5.2 

MoP 

Availability  of  information 

after  Alberts  &  Hayes,  2006:  58 

1.5. 2.1 

MoP 

Proportion  of  collected  information  which  was 
processed 

Clark  &  Moon,  2000:  Section  6 

1.5. 2.2 

MoP 

Percentage  of  Commander’s  Critical  Information 
Requirements  (CCIR)  met 

after  Clark  &  Moon,  2000: 
Section  6 

1.5. 2. 3 

MoP 

Percentage  of  Priority  Intelligence  Requirements 
(PIR)  met 

1.5. 2. 4 

MoP 

Percentage  of  Essential  Elements  of  Information 
(EEI)  met 

1.5. 2. 4.1 

MoP 

Percentage  of  EEI  from  PIR  met 

1.5.2.4.2 

MoP 

Percentage  of  EEI  from  RFI  met 

1.5. 2. 5 

MoP 

Percentage  of  commander’s  Essential  Elements  of 
Friendly  Information  (EEFI)  met 

1.5. 2. 6 

MoP 

Percentage  of  Requests  for  Intelligence  (RFI)  met 

1.6 

MoCE 

Conciseness  (i.e.,  brevity)  of  information 

JP  6-0,  2006:  Ch  I,  3 

1.6.1 

MoP 

Size  (bytes)  of  digitized  data 

1.6.1. 1 

DP 

Size  of  digitized  datum 

1.6. 1.2 

MoP 

Mean  size  of  all  digitized  data 

1.6. 1.3 

MoP 

Median  size  of  all  digitized  data 

1.6. 1.4 

MoP 

Maximum  size  of  all  digitized  data 

1.6.2 

MoP 

Time  of  analog  data  (e.g.,  spoken  voice) 

1.6. 2.1 

DP 

Time  of  analog  datum 

1.6. 2.2 

MoP 

Mean  time  of  all  analog  data 

1.6. 2. 3 

MoP 

Median  time  of  all  analog  data 

1.6. 2. 4 

MoP 

Maximum  size  of  all  analog  data 

1.7 

MoCE 

Security  of  information 

JP  6-0,  2006:  Ch  I,  3 

1.7.1 

MoP 

Probability  of  detection  of  specific  information 
traversing  the  network  of  relationships  and 
connections 

after  JP  6-0,  2006:  Ch  I,  10 

1.7.2 

MoP 

Probability  of  interception  of  specific  information 
traversing  the  network  of  relationships  and 
connections 

after  JP  6-0,  2006:  Ch  I,  10 

1.8 

MoCE 

Precision  of  information 

NDP  6,  1995:  40 

1.8.1 

MoP 

Resolution  of  observation  capability 

after  NATO  R&TO,  2006: 17 

1.8.1. 1 

DP 

Spatial  resolution  of  observation  capability 

1.8. 1.2 

DP 

Temporal  resolution  of  observation  capability 

1.8.2 

MoP 

Repeatability  of  observation  capability  (i.e., 
similarity  of  observations  taken  under  same 
conditions) 

145 


1. 8.2.1 

MoP 

Range  of  differences  in  observations  under  same 
conditions 

1. 8.2.2 

MoP 

Deviation  of  observations  under  same  conditions 
from  the  mean 

1.9 

MoCE 

Attributability  (i.e.,  pedigree)  of  information 

NATO  R&TO,  2006:  18 

1.9.1 

MoP 

Differential  between  time  information  is  received 
by  a  node  and  when  information  can  be  attributed 

1.9.2 

MoP 

Number  of  nodes  in  the  life  of  the  information  to 
which  it  can  be  attributed 

1.9.3 

MoP 

Specificity  of  a  nodes  identity 

2.0 

FO 

Quality  of  relationships/connections 

2.1 

MoCE 

Usability  of  relationships  and  connections 

2.1.1 

MoP 

Availability  of  needed  relationships  and 
connections 

2.1. 1.1 

MoP 

Percentage  of  total  known  sources  that  are  available 
via  existing  relationships  and  connections 

after  Clark  &  Moon,  2000: 
Section  6 

2.1. 1.2 

MoP 

Percentage  of  total  decision-authorized  entities  that 
are  available  via  existing  relationships  and 
connections 

2.1. 1.3 

MoP 

Percentage  of  total  allocation-authorized  entities 
that  are  available  via  existing  relationships  and 
connections 

2.1. 1.4 

MoP 

Percentage  of  total  action-authorized  entities  that 
are  available  via  existing  relationships  and 
connections 

2.1. 1.5 

MoP 

Time  between  failures  to  have  needed  relationships 
and  connections 

2.1.2 

MoP 

Reliability  of  relationships  and  connections 

2. 1.2.1 

MoP 

Duration  of  operational  failure-free  connections 

2. 1.2. 1.1 

DP 

Time  between  operational  failures  for  each 
connection 

2. 1.2. 1.2 

MoP 

Time  between  operational  failures  for  the  network 
of  connections 

2. 1.2.2 

MoP 

Probability  of  operational  failure-free  connections 

2. 1.2.2. 1 

DP 

Probability  of  operational  failure  for  each 
connection 

2.1.2.2.2 

MoP 

Probability  of  operational  failure  for  network  of 
connections 

2.1.3 

MoP 

Veracity  (i.e.,  accuracy  of  transmission)  of  needed 
relationships  and  connections 

2.1.3. 1 

MoP 

Duration  of  error-free  transmissions 

2.1.3. 1.1 

DP 

Time  between  transmission  error  for  each 
connection 

2.1.3. 1.2 

MoP 

Time  between  transmission  error  for  the  network  of 
connections 

2. 1.3. 2 

MoP 

Probability  of  error-free  transmissions 

2. 1.3. 2.1 

DP 

Probability  of  error-free  transmission  for  each 
connection 

2. 1.3. 2.2 

MoP 

Probability  of  error-free  transmission  for  the 
network  of  connections 

2.1.4 

MoP 

Utilization  of  relationships  and  connections 

after  Kasunic  &  Anderson, 

2004: 39 

2. 1.4.1 

MoP 

Frequency  of  utilization 
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2. 1.4. 1.1 

MoP 

Number  of  uses  per  unit  time  of  each  relationship 
and  connection 

2. 1.4. 1.2 

MoP 

Mean  number  of  uses  per  unit  time  of  relationships 
and  connections 

2. 1.4. 1.3 

MoP 

Median  number  of  uses  per  unit  time  of 
relationships  and  connections 

2. 1.4. 2 

MoP 

Duration  of  utilization 

2. 1.4. 2.1 

MoP 

Mean  duration  of  use  of  each  relationship  and 
connection 

2. 1.4. 2.2 

MoP 

Median  duration  of  use  of  each  relationship  and 
connection 

2.1.4.2.3 

MoP 

Minimum  duration  of  use  of  each  relationship  and 
connection 

2.1.4.2.4 

MoP 

Mean  duration  of  use  of  all  relationships  and 
connections 

2.1.4.2.5 

MoP 

Median  duration  of  use  of  each  relationship  and 
connection 

2.1.4.2.6 

MoP 

Maximum  duration  of  use  of  each  relationship  and 
connection 

2.2 

MoCE 

Security  of  relationships  and  connections 

2.2.1 

MoP 

Detection  of  relationships  and  connections 

2.2.1. 1 

MoP 

Probability  of  Detection 

2.2. 1.2 

MoP 

Mean  time  between  known  detections  by  specified 
entity 

2.2.2 

MoP 

Detection  of  information  traversing  relationship  or 
connection 

2.2.2. 1 

MoP 

Probability  of  detection  of  specific  relationship  or 
connection 

JP  6-0,  2006:  Chi,  10 

2.22.2 

MoP 

Mean  time  between  known  detections  of  specific 
relationship  or  connection  by  specified  entity 

2.2.3 

MoP 

Interception  of  information  traversing  relationship 
and  connection 

2.2.1 

MoP 

Probability  of  interception  of  information 
traversing  specific  relationship  or  connection 

JP  6-0,  2006:  Chi,  10 

2.2.2 

MoP 

Mean  time  between  known  interception  of 
information  traversing  a  specific  relationship  or 
connection 

2.3 

MoCE 

Throughput  of  relationships  and  connections 

2.3.1 

MoP 

Capacity  of  relationships  and  connections 

after  Kasunic  &  Anderson, 

2004: 39 

after  Stytz  &  Banks,  2006: 

Section  4 

2.3. 1.1 

DP 

Capacity  of  each  relationship  and  connection 

2.3. 1.2 

MoP 

Capacity  of  the  network  of  relationships  and 
connections 

2.3.2 

MoP 

Speed  of  service  the  relationships  and  connections 
are  capable  of  providing 

after  Clark  &  Moon,  2000: 
Section  6 

2.3.2.1 

DP 

Speed  of  service  each  relationship  or  connection  is 
capable  of  providing 

2.3 .2.2 

MoP 

Speed  of  service  the  network  of  relationships  and 
connections  is  capable  of  providing 

2.3.3 

MoP 

Overflow  of  needed  relationships  and  connections 

after  Kasunic  &  Anderson, 

2004: 39 

147 


2.3.3. 1 

MoP 

Quantity  of  overflow  beyond  capacity  of  needed 
relationships  and  connections 

2.3.3. 1.1 

DP 

Quantity  of  overflow  beyond  capacity  for  each 
needed  relationship  or  connection 

2.3.3. 1.2 

MoP 

Quantity  of  overflow  beyond  capacity  for  the 
network  of  relationships  and  connections 

2.3. 3.2 

MoP 

Duration  of  overflow  beyond  capacity  of  needed 
relationships  and  connections 

2.3.3.2.1 

DP 

Duration  of  overflow  beyond  capacity  for  each 
needed  relationship  or  connection 

23.3.2.2 

MoP 

Duration  of  overflow  beyond  capacity  for  the 
network  of  relationships  and  connections 

23.3.3 

MoP 

Probability  of  overflow  beyond  capacity  of  needed 
relationships  and  connections 

233.3.1 

DP 

Probability  of  overflow  beyond  capacity  for  each 
needed  relationships  or  connections 

233.3.2 

MoP 

Probability  of  overflow  beyond  capacity  for  the 
network  of  needed  relationships  and  connections 

2.4 

MoCE 

Landscape  of  the  relationships  and  connections 

2.4.1 

MoP 

Geographical  reach  of  the  relationships  and 
connections 

after  Clark  &  Moon,  2000: 
Section  1 

2.4.1. 1 

MoP 

Geographical  volume  of  relationships  and 
connections 

2.4.1. 1.1 

DP 

Geographical  volume  of  each  relationship  or 
connection 

2.4.1. 1.2 

MoP 

Mean  geographical  volume  of  relationships  and 
connections 

2.4.1.13 

MoP 

Median  geographical  volume  of  relationships  and 
connections 

2.4.1. 1.4 

MoP 

Total  geographical  volume  of  relationships  and 
connections 

2.4.2 

MoP 

Reconfigurability,  or  adaptability,  of  relationships 
and  connections  to  meet  changing  circumstances 
and/or  necessary  responses 

2.4.2. 1 

MoP 

Time  to  reconfigure 

2.4.2.1.1 

MoP 

Minimum  time  required  to  reconfigure 
relationships  and  connections  to  meet  changing 
circumstances  and/or  necessary  responses 

2.4.2.1.2 

MoP 

Mean  time  required  to  reconfigure  relationships 
and  connections  to  meet  changing  circumstances 
and/or  necessary  responses 

2.4.2.13 

MoP 

Median  time  required  to  reconfigure  relationships 
and  connections  to  meet  changing  circumstances 
and/or  necessary  responses 

2.4.2.1.4 

MoP 

Maximum  time  required  to  reconfigure 
relationships  and  connections  to  meet  changing 
circumstances  and/or  necessary  responses 

2. 4. 2.2 

MoP 

Number  of  possible  solutions  for  required 
reconfiguration  to  meet  changing  circumstances 
and/or  necessary  responses 

2.4.3 

MoP 

Interoperability  of  relationships  and  connections 
(i.e.,  ability  of  relationship  or  connection  to  be  used 
by  varying  types  of  nodes) 

after  NATO  R&TO,  2006:  20 

JP  6-0,  2006:  Ch  I,  8 

2.43.1 

MoP 

Commonality  of  relationships  and  connections 

JP  6-0,  2006:  Ch  I,  8 
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2.4.3. 1.1 

DP 

Number  of  nodes  each  relationship  or  connection  is 
capable  of  connecting  with 

2.4.3. 1.2 

MoP 

Percentage  of  nodes  which  each  relationship  or 
connection  is  capable  of  connecting  with 

2.4.3. 1.3 

MoP 

Mean  percentage  of  nodes  which  each  relationship 
or  connection  is  capable  of  connecting  with 

2.4.3. 1.4 

MoP 

Median  percentage  of  nodes  which  each 
relationship  or  connection  is  capable  of  connecting 
with 

2.4. 3.2 

MoP 

Standardization  of  relationships  and  connections 

JP  6-0,  2006:  Ch  I,  8 

2.4.3.2.1 

MoP 

Percentage  of  interfaces  which  meet 
standardization  requirements 

2.4. 3.2.2 

DP 

Percentage  of  interfaces  at  a  node  which  do  not 
meet  standardization  requirements 

2.4.3.23 

MoP 

Number  of  nodes  which  have  at  least  one  interface 
which  does  not  meet  standardization  requirements 

2.43.2.4 

MoP 

Percentage  of  nodes  which  have  at  least  one 
interface  which  does  not  meet  standardization 
requirements 

2.43.2.5 

MoP 

Number  of  nodes  which  have  no  interfaces  which 
meet  standardization  requirements 

2.43.2.6 

MoP 

Percentage  of  nodes  which  have  no  interfaces 
which  meet  standardization  requirements 

2.4.33 

MoP 

Compatibility  of  relationships  and  connections  (i.e., 
capability  of  two  or  more  relationships  or 
connections  to  exist  without  mutual  interference) 

JP  6-0,  2006:  Ch  I,  8 

2.43.1 

DP 

Minimum  stand-off  distance  of  interference  for 
each  connection 

2.43.2 

DP 

Frequency  separation  for  each  connection 

2.4.4 

MoP 

Extensibility  of  relationships  and  connections  to 
meet  changing  circumstances  and/or  necessary 
responses 

2.4.4. 1 

MoP 

Landscape  of  extension 

2.4.4. 1.1 

MoP 

Number  of  nodes  connection  is  capable  of  adding 

2.4.4. 1.2 

MoP 

Number  of  connections  capable  of  adding  a  given 
node 

2.4.4.13 

MoP 

Number  of  nodes  the  network  of  connections  are 
capable  of  adding 

2.4.4.1.4 

MoP 

Available  connection  capacity  for  each  potentially 
added  node 

2.4.4. 1.5 

MoP 

Available  total  connection  capacity  for  all 
potentially  added  nodes 

2.4. 4.2 

MoP 

Time  to  extend 

2.4.4.2.1 

MoP 

Minimum  time  required  to  add  a  relationship  and 
connection  to  meet  changing  circumstances  and/or 
necessary  responses 

2.4. 4.2.2 

MoP 

Mean  time  required  to  add  a  relationship  and 
connection  to  meet  changing  circumstances  and/or 
necessary  responses 

2.4.4.23 

MoP 

Median  time  required  to  add  a  relationship  and 
connection  to  meet  changing  circumstances  and/or 
necessary  responses 
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2.4. 4.2.4 

MoP 

Maximum  time  required  to  add  a  relationship  and 
connection  to  meet  changing  circumstances  and/or 
necessary  responses 

2.4. 4.2. 5 

MoP 

Minimum  time  required  to  add  all  relationships  and 
connections  to  meet  changing  circumstances  and/or 
necessary  responses 

2. 4. 4. 2. 6 

MoP 

Mean  time  required  to  add  all  relationships  and 
connections  to  meet  changing  circumstances  and/or 
necessary  responses 

2.4. 4.2.7 

MoP 

Median  time  required  to  add  all  relationships  and 
connections  to  meet  changing  circumstances  and/or 
necessary  responses 

2.4. 4.2. 8 

MoP 

Maximum  time  required  to  add  all  relationships  and 
connections  to  meet  changing  circumstances  and/or 
necessary  responses 

2.4.5 

MoP 

Mobility  of  nodes 

NATO  R&TO,  2006:  17 

2.4.5. 1 

MoP 

Geographical  range  of  nodes 

2.4.5. 1.1 

DP 

Geographical  range  each  node  can  maneuver  while 
maintaining  needed  relationships  or  connections 

2.4.5. 1.2 

MoP 

Mean  geographical  range  nodes  can  maneuver 
while  maintaining  needed  relationships  or 
connections 

2.4.5. 1.3 

MoP 

Median  geographical  range  nodes  can  maneuver 
while  maintaining  needed  relationships  or 
connections 

2.4. 5.2 

MoP 

Geographical  speed  of  nodes 

2.4.5.2.1 

DP 

Geographical  speed  at  which  each  node  can 
maneuver  while  maintaining  needed  relationships 
or  connections 

2.4. 5.2.2 

MoP 

Mean  geographical  speed  at  which  nodes  can 
maneuver  while  maintaining  needed  relationships 
and  connections 

2.4.5.23 

MoP 

Median  geographical  speed  at  which  nodes  can 
maneuver  while  maintaining  needed  relationships 
and  connections 

2.4.5.23 

MoP 

Maximum  geographical  speed  at  which  nodes  can 
maneuver  while  maintaining  needed  relationships 
and  connections 

3.0 

FO 

Awareness  of  Established  Intent 

3.1 

MoP 

Degree  to  which  the  established  intent  is 
understood  by  forces 

Alberts  &  Hayes,  2006:  38-39 

3.2 

MoP 

Consistency  of  established  intent  between  forces 

3.3 

MoP 

Time  differential  of  awareness  of  established  intent 
by  different  forces 

3.4 

MoP 

Differential  in  time  between  awareness  of 
established  intent  by  a  force  and  time  when 
awareness  is  needed  for  force  to  act  accordingly 

3.5 

MoP 

Degree  of  situational  familiarity  for  forces 

NATO  R&TO,  2006:  18 

4.0 

FO 

Awareness  of  Rules  and  Constraints 

4.1 

MoP 

Degree  to  which  rules  and  constraints  are 
understood  by  forces 

Alberts  &  Hayes,  2006:  42 

4.2 

MoP 

Consistency  of  awareness  between  forces  of  rules 
and  constraints  which  are  applicable  to  such  forces 
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4.3 

MoP 

Accuracy  of  awareness  of  rules  and  constraints 
compared  with  actual  rules  and  constraints 

after  Alberts  &  Hayes,  2006: 

144 

QUALITY  OF  RESPONSE 

5.0 

FO 

Quality  of  response  decision 

5.1 

MoCE 

Appropriateness  of  response  to  changing 
circumstances 

Alberts  &  Hayes,  2006:  42 

5.1.1 

MoP 

Degree  to  which  the  established  intent  is  accepted 
by  forces 

Alberts  &  Hayes,  2006:  38-39 

5.1.2 

MoP 

Consistency  of  response  with  established  intent 

5.1.3 

MoP 

Degree  to  which  rules  and  constraints  are  accepted 
by  forces 

Alberts  &  Hayes,  2006:  42 

5.1.4 

MoP 

Consistency  of  response  with  rules  and  constraints 

5.1.5 

MoP 

Degree  of  risk  to  forces  for  each  response 

5.2 

MoCE 

Timeliness  of  response  decision 

after  Alberts  &  Hayes,  2006:  43 

5.2.1 

MoP 

Time  between  receipt  of  information  concerning 
changing  circumstances  and  acknowledgement  of 
receipt 

5.2.2 

MoP 

Time  between  acknowledgement  of  receipt  of 
information  concerning  changing  circumstances 
and  response  decision 

5.2.2. 1 

MoP 

Time  between  acknowledgement  of  receipt  of 
information  concerning  changing  circumstances 
and  response  option  being  developed 

5 .2.2.2 

MoP 

Time  between  response  option  being  developed  and 
response  decision 

5.2.3 

MoP 

Time  between  response  decision  and  order  of 
response  execution  by  decision-authorized  entity 

5.2.4 

MoP 

Time  between  order  of  response  execution  and  time 
required  to  allocate  and  execute  response 

5.3 

MoCE 

Distribution  of  response  decision  capability 

5.3.1 

MoP 

Mean  number  of  connections  between  decision- 
authorized  entity  and  action-authorized  entity 

5.3.2 

MoP 

Median  number  of  connections  between  decision- 
authorized  entity  and  action-authorized  entity 

5.3.3 

MoP 

Maximum  number  of  connections  between 
decision-authorized  entity  and  action-authorized 
entity 

5.3.4 

MoP 

Percentage  of  entities  connected  by  existing 
relationships  and  connections  which  are  authorized 
to  make  a  specific  decision  concerning  a  specific 
change  in  circumstances 

5.4 

MoCE 

Response  solution  space 

5.4.1 

MoP 

Number  of  distinct  response  solutions  generated  by 
decision-authorized  entities  concerning  a  specific 
change  in  circumstances 

5.4.2 

MoP 

Number  of  distinct  response  solutions  concerning  a 
specific  change  in  circumstances  which,  if  selected 
concurrently,  do  not  interfere  with  each  other  in 
execution 

5.5 

MoCE 

Consistency  of  response  between  decision- 
authorized  entities 

5.5.1 

MoP 

Number  of  action-authorized  entities  with 
conflicting  orders  from  decision-authorized  entities 
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5.5.2 

MoP 

Percentage  of  action-authorized  entities  with 
conflicting  orders  from  decision-authorized  entities 

6.0 

FO 

Quality  of  allocations 

6.1 

MoCE 

Appropriateness  of  allocations 

6.1.1 

MoP 

Degree  to  which  forces  understand  the  roles  and 
responsibilities  allocated  to  them 

Alberts  &  Hayes,  2006:  41 

6.1.2 

MoP 

Degree  to  which  forces  accept  the  roles  and 
responsibilities  allocated  to  them 

6.1.3 

MoP 

Feasibility  of  role  and  responsibility  allocations 

after  NATO  R&TO,  2006:  24 

6.1.3. 1 

MoP 

Availability  of  material  for  allocation 

after  Alberts  &  Hayes,  2006: 

58 

6. 1.3. 2 

MoP 

Number  of  action-authorized  entities  which  are 
allocated  a  role  or  responsibility  which  they  cannot 
accomplish 

6. 1.3. 3 

MoP 

Percentage  of  action-authorized  entities  which  are 
allocated  a  role  or  responsibility  which  they  cannot 
accomplish 

6.2 

MoCE 

Timeliness  of  allocations 

6.2.1 

MoP 

Time  between  order  of  response  execution  by 
decision-authorized  entity  and  completion  of 
allocations  by  allocation-authorized  entity 

6.2.2 

MoP 

Time  between  allocation  of  role  or  responsibility 
and  commencement  of  role  or  responsibility  by 
action-authorized  entity 

6.2.3 

MoP 

Time  between  allocation  of  role  or  responsibility 
and  time  required  to  execute  response  action 

6.3 

MoCE 

Distribution  of  response  allocation  capability 

6.3.1 

MoP 

Mean  number  of  connections  between  allocation- 
authorized  entity  and  action-authorized  entity 

6.3.2 

MoP 

Median  number  of  connections  between  allocation- 
authorized  entity  and  action-authorized  entity 

6.3.3 

MoP 

Maximum  number  of  connections  between 
allocation-authorized  entity  and  action-authorized 
entity 

6.3.4 

MoP 

Percentage  of  entities  connected  by  existing 
relationships  and  connections  which  are  authorized 
to  make  allocations  concerning  a  specific  decision 

6.4 

MoCE 

Completeness  of  role  and  responsibility  allocation 

Alberts  &  Hayes,  2006:  41 

6.4.1 

MoP 

Number  of  roles  and  responsibilities  which  are 
required  for  the  specific  decision  which  are  not 
allocated 

6.4.2 

MoP 

Percentage  of  roles  and  responsibilities  which  are 
required  for  the  specific  decision  which  are  not 
allocated 

Table  20.  System  Objectives  Hierarchy 


C.  SELECTED  MEASURES  OF  MERIT 

The  focus  of  this  thesis  was  on  the  engineering  of  a  command  and  control  system 

for  naval  forces  at  the  tactical  level  of  war  which  could  incorporate  concepts  associated 

with  network-centric  warfare.  The  systems  objective  hierarchy  presented  in  the  previous 
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section  is  far  too  large,  given  the  scope  of  this  thesis,  for  an  effective  analysis  of  the  value 
of  the  C2  system.  Therefore,  a  reasonable  subset  of  the  measures  was  selected  for  the 
remaining  phases  of  the  engineering  process.  The  refined  problem  statement  generated 
during  the  operational  concept  development  served  as  a  guide  for  the  selection.  Recall 
that  the  refined  problem  statement  is: 

A  responsive  and  robust  command  and  control  system  which  connects 
dispersed  forces  and  enables  such  forces  to  self-synchronize  and  allocate 
resources  to  mass  effects  in  order  to  meet  the  established  intent  at  the 
tactical  level  of  war. 

Responsive  is  the  timeliness  in  which  the  command  and  control  system  can 
identify  changing  circumstances,  determine  the  impact  of  the  changing  circumstances, 
and  enact  an  appropriate  response.  Selected  measures  of  performance  applying  to  the 


concept  of  responsive  are  presented  in  Table  21. 


1.3.1 

MoP 

Time  between  changing  circumstances  and  observation 

1.3.2 

MoP 

Time  between  the  observation  and  the  completion  of  processing  the  data  into 
information 

1.3. 4. 4 

MoP 

Probability  of  shelf-life  is  less  then  time  between  updates 

1.9.1 

MoP 

Differential  between  time  information  is  received  by  a  node  and  when  information  can 
be  attributed 

2.4.2.1.3 

MoP 

Median  time  required  to  reconfigure  relationships  and  connections  to  meet  changing 
circumstances  and/or  necessary  responses 

2.4. 4.2.7 

MoP 

Median  time  required  to  add  all  relationships  and  connections  to  meet  changing 
circumstances  and/or  necessary  responses 

5.2.1 

MoP 

Time  between  receipt  of  information  concerning  changing  circumstances  and 
acknowledgement  of  receipt 

5.2.2. 1 

MoP 

Time  between  acknowledgement  of  receipt  of  information  concerning  changing 
circumstances  and  response  option  being  developed 

5 .2.2.2 

MoP 

Time  between  response  option  being  developed  and  response  decision 

5.2.3 

MoP 

Time  between  response  decision  and  order  of  response  execution  by  decision- 
authorized  entity 

6.2.1 

MoP 

Time  between  order  of  response  execution  by  decision-authorized  entity  and 
completion  of  allocations  by  allocation-authorized  entity 

6.2.2 

MoP 

Time  between  allocation  of  role  or  responsibility  and  commencement  of  role  or 
responsibility  by  action-authorized  entity 

Table  2 1 .  Responsive  Measures  of  Performance 


Robust  it  is  meant  the  ability  of  the  command  and  control  system  to  identify  a 
range  of  changing  circumstances,  detennine  the  impact  of  the  changing  circumstances, 
and  enact  an  appropriate  response.  Selected  measures  of  merit  applying  to  the  concept  of 
robust  are  presented  in  Table  22. 
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1.2.1 

MoP 

Number  of  sources  confirming  information 

1.5. 2. 4 

MoP 

Percentage  of  Essential  Elements  of  Information  (EEI)  met 

1.5. 2. 5 

MoP 

Percentage  of  commander’s  Essential  Elements  of  Friendly  Information  (EEFI)  met 

1.8.1. 1 

DP 

Spatial  resolution  of  observation  capability 

1.8. 1.2 

DP 

Temporal  resolution  of  observation  capability 

1.9.2 

MoP 

Number  of  nodes  in  the  life  of  the  information  to  which  it  can  be  attributed 

2. 1.2. 1.2 

MoP 

Time  between  operational  failures  for  the  network  of  connections 

2.1.2.2.2 

MoP 

Probability  of  operational  failure  for  network  of  connections 

2.3.3. 1.2 

MoP 

Quantity  of  overflow  beyond  capacity  for  the  network  of  relationships  and 
connections 

2. 4. 2.2 

MoP 

Number  of  possible  solutions  for  required  reconfiguration  to  meet  changing 
circumstances  and/or  necessary  responses 

2.4.3. 1.4 

MoP 

Median  percentage  of  nodes  which  each  relationship  or  connection  is  capable  of 
connecting  with 

2.4.4. 1.3 

MoP 

Number  of  nodes  the  network  of  connections  are  capable  of  adding 

5.4.1 

MoP 

Number  of  distinct  response  solutions  generated  by  decision-authorized  entities 
concerning  a  specific  change  in  circumstances 

Table  22.  Robust  Measures  of  Performance  and  Dimensional  Parameters 


Dispersed  forces  are  geographically  dispersed  as  well  as  dispersed  on  the  network 
which  connects  the  forces.  Selected  measures  of  merit  applying  to  the  concept  of 


dispersed  forces  are  presented  in  Table  23. 


1.4. 1.2 

MoP 

Percentage  of  nodes  which  are  capable  of  viewing  information 

1. 4.2.2 

MoP 

Percentage  of  nodes  which  a  capable  of  acting  information 

2.1. 1.2 

MoP 

Percentage  of  total  decision-authorized  entities  that  are  available  via  existing 
relationships  and  connections 

2.1. 1.3 

MoP 

Percentage  of  total  allocation-authorized  entities  that  are  available  via  existing 
relationships  and  connections 

2.1. 1.4 

MoP 

Percentage  of  total  action-authorized  entities  that  are  available  via  existing 
relationships  and  connections 

2.4.1. 1.4 

MoP 

Total  geographical  volume  of  relationships  and  connections 

2.4.5. 1.3 

MoP 

Median  geographical  range  nodes  can  maneuver  while  maintaining  needed 
relationships  or  connections 

5.3.2 

MoP 

Median  number  of  connections  between  decision-authorized  entity  and  action- 
authorized  entity 

5.3.4 

MoP 

Percentage  of  entities  connected  by  existing  relationships  and  connections  which  are 
authorized  to  make  a  specific  decision  concerning  a  specific  change  in  circumstances 

6.3.2 

MoP 

Median  number  of  connections  between  allocation-authorized  entity  and  action- 
authorized  entity 

6.3.4 

MoP 

Percentage  of  entities  connected  by  existing  relationships  and  connections  which  are 
authorized  to  make  allocations  concerning  a  specific  decision 

Table  23.  Dispersed  Forces  Measures  of  Performance 
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Self-synchronization  is  the  ability  of  a  force  to  “organize  and  synchronize 
complex  warfare  activities  from  the  bottom  up”  [Cebrowski  &  Garstka,  1998].  Self¬ 
synchronization  includes  the  ability  for  the  forces  to  allocate  resources  at  their  disposal  to 
mass  effects  to  meet  an  established  intent.  Established  intent  is  used  instead  of  the 
traditional  commander ’s  intent  since  self-synchronizing  forces,  which  either  may  not  be 
connected  with  their  commander  or  may  not  have  a  commander  (e.g.,  coalition  forces), 
may  be  capable  identifying  and  responding  to  emerging  circumstances  which  alter  the 
operating  environment  and  their  purpose.  Selected  measures  of  merit  applying  to  the 


concept  of  self-synchronization  are  presented  in  Table  24. 


3.2 

MoP 

Consistency  of  established  intent  between  forces 

4.2 

MoP 

Consistency  of  awareness  between  forces  of  rules  and  constraints  which  are  applicable 
to  such  forces 

5.1.2 

MoP 

Consistency  of  response  with  established  intent 

5.1.4 

MoP 

Consistency  of  response  with  rules  and  constraints 

5.5.2 

MoP 

Percentage  of  action-authorized  entities  with  conflicting  orders  from  decision- 
authorized  entities 

6. 1.3. 3 

MoP 

Percentage  of  action-authorized  entities  which  are  allocated  a  role  or  responsibility 
which  they  cannot  accomplish 

6.4.2 

MoP 

Percentage  of  roles  and  responsibilities  which  are  required  for  the  specific  decision 
which  are  not  allocated 

Table  24.  Self-synchronization  Measures  of  Performance 


The  entire  set  of  selected  measures  is  presented  below  in  Table  25. 


1.2.1 

MoP 

Number  of  sources  confirming  information 

1.3.1 

MoP 

Time  between  changing  circumstances  and  observation 

1.3.2 

MoP 

Time  between  the  observation  and  the  completion  of  processing  the  data  into 
information 

1.3. 4. 4 

MoP 

Probability  of  shelf-life  is  less  then  time  between  updates 

1.4. 1.2 

MoP 

Percentage  of  nodes  which  are  capable  of  viewing  information 

1. 4.2.2 

MoP 

Percentage  of  nodes  which  a  capable  of  acting  information 

1.5. 2. 4 

MoP 

Percentage  of  Essential  Elements  of  Information  (EEI)  met 

1.5.2. 5 

MoP 

Percentage  of  commander’s  Essential  Elements  of  Friendly  Information  (EEFI)  met 

1. 8.1.1 

DP 

Spatial  resolution  of  observation  capability 

1.8. 1.2 

DP 

Temporal  resolution  of  observation  capability 

1.9.2 

MoP 

Number  of  nodes  in  the  life  of  the  information  to  which  it  can  be  attributed 

1.9.1 

MoP 

Differential  between  time  information  is  received  by  a  node  and  when  information  can 
be  attributed 

2.1. 1.2 

MoP 

Percentage  of  total  decision-authorized  entities  that  are  available  via  existing 
relationships  and  connections 

2.1. 1.3 

MoP 

Percentage  of  total  allocation-authorized  entities  that  are  available  via  existing 
relationships  and  connections 

2.1. 1.4 

MoP 

Percentage  of  total  action-authorized  entities  that  are  available  via  existing  relationships 
and  connections 

2. 1.2. 1.2 

MoP 

Time  between  operational  failures  for  the  network  of  connections 

2.1.2.2.2 

MoP 

Probability  of  operational  failure  for  network  of  connections 
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2.3.3. 1.2 

MoP 

Quantity  of  overflow  beyond  capacity  for  the  network  of  relationships  and  connections 

2.4.1. 1.4 

MoP 

Total  geographical  volume  of  relationships  and  connections 

2.4.2.1.3 

MoP 

Median  time  required  to  reconfigure  relationships  and  connections  to  meet  changing 
circumstances  and/or  necessary  responses 

2. 4. 2.2 

MoP 

Number  of  possible  solutions  for  required  reconfiguration  to  meet  changing 
circumstances  and/or  necessary  responses 

2.4.3. 1.4 

MoP 

Median  percentage  of  nodes  which  each  relationship  or  connection  is  capable  of 
connecting  with 

2.4.4. 1.3 

MoP 

Number  of  nodes  the  network  of  connections  are  capable  of  adding 

2.4. 4.2.7 

MoP 

Median  time  required  to  add  all  relationships  and  connections  to  meet  changing 
circumstances  and/or  necessary  responses 

2.4.5. 1.3 

MoP 

Median  geographical  range  nodes  can  maneuver  while  maintaining  needed  relationships 
or  connections 

3.2 

MoP 

Consistency  of  established  intent  between  forces 

4.2 

MoP 

Consistency  of  awareness  between  forces  of  rules  and  constraints  which  are  applicable 
to  such  forces 

5.1.2 

MoP 

Consistency  of  response  with  established  intent 

5.1.4 

MoP 

Consistency  of  response  with  rules  and  constraints 

5.2.1 

MoP 

Time  between  receipt  of  information  concerning  changing  circumstances  and 
acknowledgement  of  receipt 

5.2.2. 1 

MoP 

Time  between  acknowledgement  of  receipt  of  information  concerning  changing 
circumstances  and  response  option  being  developed 

5 .2.2.2 

MoP 

Time  between  response  option  being  developed  and  response  decision 

5.2.3 

MoP 

Time  between  response  decision  and  order  of  response  execution  by  decision- 
authorized  entity 

5.3.2 

MoP 

Median  number  of  connections  between  decision-authorized  entity  and  action- 
authorized  entity 

5.3.4 

MoP 

Percentage  of  entities  connected  by  existing  relationships  and  connections  which  are 
authorized  to  make  a  specific  decision  concerning  a  specific  change  in  circumstances 

5.4.1 

MoP 

Number  of  distinct  response  solutions  generated  by  decision-authorized  entities 
concerning  a  specific  change  in  circumstances 

5.5.2 

MoP 

Percentage  of  action-authorized  entities  with  conflicting  orders  from  decision- 
authorized  entities 

6. 1.3. 3 

MoP 

Percentage  of  action-authorized  entities  which  are  allocated  a  role  or  responsibility 
which  they  cannot  accomplish 

6.2.1 

MoP 

Time  between  order  of  response  execution  by  decision-authorized  entity  and  completion 
of  allocations  by  allocation-authorized  entity 

6.2.2 

MoP 

Time  between  allocation  of  role  or  responsibility  and  commencement  of  role  or 
responsibility  by  action-authorized  entity 

6.3.2 

MoP 

Median  number  of  connections  between  allocation-authorized  entity  and  action- 
authorized  entity 

6.3.4 

MoP 

Percentage  of  entities  connected  by  existing  relationships  and  connections  which  are 
authorized  to  make  allocations  concerning  a  specific  decision 

6.4.2 

MoP 

Percentage  of  roles  and  responsibilities  which  are  required  for  the  specific  decision 
which  are  not  allocated 

Table  25.  Selected  Measures  of  Merit 
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APPENDIX  E:  FUNCTIONAL  DECOMPOSITION 


A  function  is  a  process  that  takes  inputs  and  transforms  them  into  outputs  [Buede, 
2000:  178].  Recall  that  a  system  is  “a  set  of  components  (subsystems,  segments)  acting 
together  to  achieve  a  set  of  common  objectives  via  the  accomplishment  of  a  set  of  tasks” 
[Buede,  2000:  38],  A  system,  therefore,  is  defined  by  1)  its  set  of  objectives  and  2)  the 
functions  required  for  it  to  achieve  such  set  of  objectives.  As  discussed  in  Appendix  C: 
External  Systems  Diagram,  the  execution  of  the  C2  process  is  the  objective  of  a  C2 
system.  The  functional  architecture  describes  how  the  system  transforms  the  given  inputs 
into  the  desired  outputs. 

This  appendix  will  describe  concepts  pertinent  to  the  functional  decomposition  of 
a  naval  tactical  command  and  control  system  not  previously  described  in  the  body  of  this 
thesis.  The  first  section  will  discuss  C2  functions  identified  by  past  researchers.  The 
second  section  will  present  concepts  concerning  information  and  human  decision  making 
influential  to  the  definition  of  functions  and  sub-functions. 

A.  SURVEY  OF  COMMAND  AND  CONTROL  FUNCTIONS 

As  during  the  development  of  the  operational  concept,  a  publication  review  was 
conducted  to  provide  the  author  with  a  foundational  knowledge  of  the  functions  of 
command  and  control.  Though  by  no  means  an  exhaustive  review,  the  author  did  seek  to 
review  many  of  most  referenced  contemporary  publications.  As  stated  above,  the 
execution  of  the  C2  process  is  the  objective  of  a  C2  system.  Therefore,  many  of  the 
publications  reviewed  contained  conceptual  models  of  the  C2  process.  Table  26. 
through  Table  32.  present  functions  of  C2  systems  and  subsystems  taken  from  these 
references. 
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Command  and  Control  Functions 

Establish  Intent 

Define  roles, 
responsibilities  and 
relationships 

Establish  rules  and 
constraints 

Monitor  and  assess 
the  situation  and 
progress 

Inspiring, 
motivating,  and 
engendering  trust 

Training  and 
education 

Provisioning 

Table  26.  Command  and  Control  Functions 
[from  Alberts  &  Hayes,  2006:  35-36] 


Command  and  Control  Functions 

Collecting 

Information 

Storing 

Information 

Retrieving 

Information 

Filtering 

Information 

Classifying 

Information 

Distributing 

Information 

Displaying 

Information 

Form  Estimate 
of  Situation 

Establish 

Objectives 

Make  Decision 

Plan 

Draft  Orders 

Transmit 

Orders 

Execute 

Orders 

Monitor  Order 
Execution  with 
Feedback 

Table  27.  Command  and  Control  Functions 
[from  Van  Creveld,  1985:  6-7] 


Command  and  Control  Functions 

Sense 

Process 

Compare 

Decide 

Act 

Table  28.  Command  and  Control  Functions  [from  Lawson,  1981] 


Command  and  Control  Functions 

Sense 

Assess 

Generate 

Select 

Plan 

Act 

Table  29.  Command  and  Control  Functions  [after  Levis  &  Athans,  1988] 
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Defensive  Command  and  Control  Functions 

Threat  Detection 

Target  Tracking 

Discrimination 

Identification 

Battle  Planning 

W  eapon-to-Target 
Assignment 

Engagement 

Control 

Damage 

Assessment 

Table  30.  Defensive  Command  and  Control  Functions 
[from  Athans,  1986:  6-7] 


Target  Engagement  Functions 

Find 

Fix 

Track 

Target 

Engage 

Assess 

Table  3 1 .  Target  Engagement  Functions  [from  JP  3-60,  2007] 


Communications  Systems  Functions 

Acquire 

Information 

Store 

Information 

Control  other 
Communication 
Functions 

Disseminate 

Information 

Process 

Information 

Transport 

Information 

Protect 

Information 

Present 

Information 

Table  32.  Communications  Systems  Functions 
[from  JP  6-0,  2006:  Ch  I,  6-8] 

B.  INFORMATION  AND  HUMAN  DECISION  MAKING 


The  basic  external  systems  diagram  developed  in  the  operational  concept  shows 
that  people  and  the  communications  &  information  systems  are  two  categories  of 
components  of  the  C2  system  and  that  inputs  to  and  outputs  form  the  system,  along  with 
the  cross-communication  between  the  subsystems,  is  information.  Understanding  what 
humans  and  automated  systems  can  bring  to  the  C2  process  can  be  beneficial  in  the 
decomposition  of  the  top-level  functions.  Additionally,  understanding  the  forms  of 
information  and  the  processes  to  convert  one  form  of  information  into  another  can 
enlighten  the  system  engineer  to  other  potential  sub-functions  of  the  C2  system. 
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1.  Cognitive  Hierarchy 

Information  comes  in  many  forms.  One  form  of  information  is  transformed  to 
another  fonn  of  information  through  a  process.  Ackoff  [1989]  posits  that  the  forms  of 
information  are  actually  structured  in  a  hierarchy  of  five  forms.  The  lowest  fonn  of 
information  in  his  hierarchy  is  data,  which  he  contends  is  a  product  of  observation. 
Information,  the  next  highest  form  of  information  in  his  hierarchy,  is  data  which  has  been 
“processed  into  a  useable  (i.e.,  relevant)  form”  [Ackoff,  1989:  3].  Learning,  either  by 
instruction  or  by  extracting  it  from  experience,  transforms  information  into  knowledge 
[Ackoff,  1989:  4].  Ackoff  describes  learning  with  changing  conditions  as  adaption.  He 
then  contends  that  systematic  learning  and  adaption,  through  diagnosis  and  prescription, 
transforms  knowledge  into  understanding.  Finally,  wisdom  is  understanding  with  value, 
judgment  being  the  mental  function  which  transforms  understanding  into  wisdom. 
Ackoff  s  hierarchy  of  infonnation  and  processes  is  presented  in  Figure  46. 

Wisdom  ( 


Figure  46.  Hierarchy  of  Information  Forms  [after  Ackoff,  1989] 

There  are  many  concepts  within  Ackoff  s  hierarchy  which  have  significant 
pertinence  to  this  thesis.  First,  the  most  obvious  given  the  explanation  above,  is  that 
information  comes  in  many  forms.  Second,  non-human  systems  can  be  built  that  perfonn 
all  of  the  processes  except  judgment,  which  is  solely  a  capability  of  humans.  This  differs 
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Hierarchy  of  Information  Forms 


A 

Data 


significantly  from  similar  hierarchies  described  in  Naval  Doctrine  Publication  6  [1995: 
21]  and  Marine  Corps  Doctrine  Publication  6  [1996:  67]  that  contend  knowledge  and 
above  requires  cognition,  a  human-only  capability.  Figure  47.  and  Figure  48.  present 
each,  respectively.  The  third  significant  idea  which  is  inferred  from  Ackoff  s  hierarchy  is 
that,  just  as  there  is  a  process  to  convert  one  form  to  a  higher  form,  there  must  be  a 
process  to  convert  one  form  to  a  lower  form.  This  is  best  understood  with  the  fourth 
significant  idea,  also  inferred,  that  transmission  of  a  form  of  infonnation  requires  that  it 
be  transformed  into  data. 


Figure  47.  Cognitive  Hierarchy  [after  NDP  6,  1995:  21] 
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Information  Hierarchy 

|  Judgement  | — 

— ►!  Understanding 

i 

Cognition  - H  Knowledge  | 

Processing  |— 

i  \ - 1 - 

►1  Processed  Data  j 

▲ 

Data 

Figure  48.  Information  Hierarchy  [after  MCDP  6,  1996:  67] 


To  understand  the  third  and  fourth  ideas,  take  the  example  where  one  person  has  a 
piece  of  knowledge  which  they  wish  to  share  with  another  person.  As  Ackoff  explains, 
this  is  done  through  instruction  [pg.  4].  To  gain  knowledge,  the  student  has  to  learn 
information.  To  leam  the  infonnation,  though,  requires  the  student  to  observe  the 
instruction  by  the  instructor.  The  instructor,  therefore,  must  transfonn  his  knowledge 
into  data  for  the  student  to  leam. 

Communication  of  information,  in  whatever  form,  is  based  on  the  exchange  of 
data  through  observation.  Examples  are  numerous  in  human-to-machine  communication 
(e.g.,  keyboards),  machine-to-human  communication  (e.g.,  visual  displays),  and  machine- 
to-machine  communications  (e.g.,  common  protocols).  A  C2  system  interfaces  with 
external  systems.  Therefore,  it  must  be  capable  of  transfonning  its  inputs,  which  are  in 
the  form  of  data,  into  useful  information.  It  must  also  be  capable  of  transforming  its 
useful  information  into  data  to  become  output.  Process,  and  its  inverse  function,  must  be 
a  function  of  the  C2  system.  Learning,  diagnose,  prescribe,  and  their  inverse  functions 
are  candidate  functions  as  well.  Judgment  and  its  inverse  are  also  candidate  functions, 
but,  as  Ackoff  contends,  can  only  be  executed  by  human  components  of  the  C2  system. 
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2.  Human  Decision  Making 

People  and  communications  &  information  systems  are  two  types  of  components 
of  a  C2  system.  The  significance  of  these  two  categories  is  that  they  highlight  the  types 
of  entities  within  the  system  which  can  fill,  partially  or  wholly,  the  functions  of  the  C2 
system  -  humans  and  automated  systems.  Understanding  what  humans  and  automated 
systems  can  bring  to  the  C2  process  can  be  beneficial  in  the  decomposition  of  the  top- 
level  functions.  The  first  step,  then,  is  to  review  the  process  by  which  humans  make 
decisions.  Also,  given  that  the  commander  is  an  external  system,  this  review  can  identify 
inputs  for  the  commander  which  may  subsequently  be  outputs  from  the  C2  system. 

Human  decision  making  is  a  major  reason  why  command  and  control  has  been  an 
enigma.  Understanding  and  modeling  human  decision  making  has  plagued  engineers  and 
analysts  for  as  long  as  they  have  studied  command  and  control.  Many  have  developed 
conceptual  models  to  explain  all  or  part  of  the  process.  Despite  the  mystery  of  human 
decision  making,  reviewing  several  of  these  conceptual  models  of  the  process  can 
enlighten  the  system  engineer  to  potential  sub-functions  of  generate  response  options  and 
other  top-level  functions.  The  first  conceptual  model  to  review,  which  is  perhaps  the 
most  famous  amongst  military  scholars,  is  the  Observation-Orientation-Decision-Action 
(OODA)  Loop  presented  by  Boyd  [1996].  A  depiction  of  the  OODA  Loop  from  Boyd’s 
unpublished  lecture  notes  is  presented  in  Figure  49. 

Boyd’s  OODA  Loop  is  the  culmination  of  decades  of  research  and  analysis  which 
began  with  his  study  of  air  attack,  then  air-to-air  combat,  then  finally  to  a  more  general 
theory  of  competition.  The  OODA  Loop  has  been  applied  by  contemporary  scholars  to 
describe  the  C2  process  for  groups,  but  Boyd’s  original  intentions  leading  to  the  OODA 
loop  was  to  describe  the  process  an  individual  uses  when  combating  another  individual. 

It  is  from  this  individual,  human  decision  making  view  that  the  OODA  loop  will  be  used 
for  generating  sub-functions.  Boyd  did  not  formally  publish  any  of  his  work,  choosing 
rather  to  give  lectures  concerning  his  concepts,  and  unfortunately  the  author  was  not  able 
to  attend  any  of  his  lectures.  Therefore,  the  discussion  below  is  a  result  of  the  author’s 
review  of  Boyd’s  unpublished  lecture  notes. 
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The  OODA  Loop  is  a  relatively  straightforward  conceptual  model  with  nearly  the 
entire  concept  neatly  depicted  in  Figure  49.  Competition  for  an  individual  is  an  iterative 
process  of  four  phases  -  observation,  orientation,  decision,  and  action.  Each  phase  feeds 
forward  to  the  next  phase  and  each  phase  provides  feedback  to  observation.  There  are  six 
inputs  to  the  process,  or  in  other  words  six  inputs  to  the  human  decision  making  system. 
Three  of  the  inputs  are  within  observation  (outside  information,  unfolding  circumstances, 
and  unfolding  environmental  interaction)  and  three  within  orientation  (cultural  traditions, 
genetic  heritage,  and  previous  experiences;  new  information  is  product  of  observation). 
These  six  inputs  are  analyzed  and  synthesized  during  orientation  to  feed  the  decision  and 
action  phases.  The  analysis  and  synthesis  of  the  inputs,  as  Boyd  contends,  is  the  most 
crucial  to  the  entire  decision  making  process. 

The  second  O,  orientation  -  as  the  repository  of  our  genetic  heritage,  cultural 
tradition,  and  previous  experiences  -  is  the  most  important  part  of  the  O-O-D-A  loop 
since  it  shapes  the  way  we  observe,  the  way  we  decide,  and  the  way  we  act.  [Boyd, 

1987:  26] 

From  this  basic  review  of  the  OODA  Loop,  the  system  engineer  can  conclude  that 
the  human  decision  making  system  is  comprised  of  six  top-level  functions  -  observe, 
orient,  hypothesize,  test,  decide,  and  act.  In  addition,  the  sub-functions  of  orient  are 
analyze  and  synthesize. 
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Observation 


Orientation 


Decision 


Action 


Figure  49.  OODA  Loop  [from  Boyd,  1996] 

The  second  conceptual  model  to  review  is  the  Recognition-Primed  Decision 
Making  (RPD)  model  presented  by  Klein  [1988].  Klein  contends  that  there  are  two  types 
of  approaches  to  decision  making,  one  analytical  and  the  other  recognitional.  Analytical 
approaches,  Klein  argues,  are  most  appropriate  in  situations  with  “low  time  pressure, 
need  for  careful  documentation,  and  context  free  task  with  many  components”  while 
recognitional  approaches  are  appropriate  in  situations  with  “high  time  pressure,  highly 
experienced  decision  maker,  low  need  for  precision,  and  strong  contextual  influences” 
[1988,  86].  From  previous  work  with  other  researchers,  Klein  presents  and  discuses  the 
RPD  model  developed,  which  is  shown  in  Figure  50. 

In  the  simplest  case  of  the  RPD  model,  the  decision  maker  uses  cues  of  the 
situation  and  knowledge  to  recognize  a  situation.  The  recognition  also  incorporates  the 
goals  which  “can  be  achieved,  what  cues  to  monitor,  and  other  types  of  expectancies” 
[Klein,  1988:  87].  From  this  recognition,  the  decision  maker  identifies  the  typical 
response  and  implements  the  action.  In  the  next  case,  when  time  is  available,  the 
decision  maker  evaluates  the  typical  action  and  implements  the  action.  No  other  actions 
other  than  the  typical  action  are  considered  or  evaluated.  In  the  final  case  of  RPD,  again 
when  time  is  available,  the  decision  maker  evaluates  the  typical  reaction  from  a  queue  of 
actions.  The  action  may  be  implemented,  modified,  or  rejected.  If  the  action  is  rejected, 
another  action  from  the  queue  is  evaluated  and  then  implemented,  modified,  or  rejected. 
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This  process  continues  until  an  action  is  selected  and  implemented.  A  difference  between 
recognitional  and  analytical  approaches  is  that,  for  example,  in  the  final  case  of  RPD  the 
actions  are  evaluated  in  series  and  are  not  compared  with  each  other. 


(a)  Automatic  RPD 


(b)  Verify  RPD 


(c)  Serial  RPD 


Figure  50.  Recognition-Primed  Decision  Making  [from  Klein,  1988] 

Though  both  conceptual  models  have  yielded  relatively  few  ideas  for  sub¬ 
functions  of  the  C2  system,  they  have  identified  system  outputs  and  possible  constraints 
to  the  outputs.  A  C2  system’s  outputs  to  the  decision  making  person,  when  one  exists, 
include  information  concerning  the  environment,  the  interaction  between  the  force  and 
the  environment,  and  any  other  outside  information  pertinent  to  the  environment  (e.g., 
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updated  ROE).  Constraints  on  the  C2  system  may  be  to  present  the  outputs  to  the 
decision  maker  taking  into  account  inputs  outside  of  the  C2  system,  namely  genetic 
heritage,  cultural  traditions,  and  previous  experiences.  In  addition,  when  time  is  critical, 
it  may  be  best  for  the  C2  system  to  present  response  options  in  series  rather  than  in  a  set. 
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APPENDIX  F:  INPUT-OUTPUT  RELATIONSHIPS 


After  the  functional  hierarchy  was  detailed,  the  next  phase  of  the  functional 
architecture  development  was  to  describe  the  relationships  between  inputs  and  outputs  of 
the  system.  During  the  operational  concept,  interaction  diagrams  were  developed 
demonstrating  the  relationship  between  certain  inputs,  outputs,  and  the  system.  This 
appendix  presents  the  further  detail  to  explain  the  process  (i.e.,  sequence  of  functions)  by 
which  inputs  are  converted  into  outputs. 

Below  is  a  collection  of  relationship  diagrams  developed  for  this  thesis  using 
IDEFO.  The  color  selection  of  lines  and  font  are  not  standard  for  IDEFO  but  were 
implemented  to  make  the  relationship  diagrams  more  easily  readable.  Red  lines  and  red, 
italic,  sans-serif  fonts  denote  procedures  and  controls,  which  will  be  discussed  in  the 
physical  architecture.  Blue  lines  and  blue,  bold,  serif  fonts  denote  mechanisms,  again 
which  will  be  discussed  in  the  physical  architecture.  Black  lines  and  black,  sans  serif 
fonts  denote  inputs  and  outputs.  In  those  instances  where  an  output  of  one  function  was  a 
control  for  another  function,  the  line  and  font  was  drawn  in  red. 

The  sub-diagrams  presented  below  denote  mechanisms  which  correspond  to 
generic  physical  components  which  were  developed  in  the  physical  architecture.  Specific 
mechanisms,  or  instantiated  physical  components,  for  each  function  were  identified  and 
finalized  during  the  development  of  the  operational  architecture.  Further  discussion  of 
the  mechanism,  shown  in  the  following  figures,  is  presented  in  the  physical  architecture 
and  operational  architecture  discussions. 
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Figure  5 1 .  Relationship  Diagram  -  A-0 
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Figure  52. 


Relationship  Diagram  -  AO 
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Figure  53.  Relationship  Diagram  -  A02 
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Figure  54.  Relationship  Diagram  -  A02 1 
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Figure  55.  Relationship  Diagram  -  A022 
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Figure  56. 


Relationship  Diagram  -  A05 
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Incomplete  Response; 
Illegal  Response; 
Immoral  Response 


Figure  57. 


Relationship  Diagram  -  A05 1 
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Figure  58.  Relationship  Diagram  -  A05 1 1 
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Figure  59.  Relationship  Diagram  -  A052 
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Figure  60. 


Relationship  Diagram  -  A06 
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Figure  61. 


Relationship  Diagram  -  A06 1 
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Figure  62 .  Relationship  Diagram  -  A06 1 3 
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Figure  63 .  Relationship  Diagram  -  A06 1 4 
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APPENDIX  G:  OPERATIONAL  ARCHITECTURE 


The  operational  architecture  provides  a  description  of  the  system  design, 
incorporating  the  products  of  the  operational  concept,  functional  architecture,  and 
physical  architecture.  This  appendix  provides  further  documentation  concerning  the 
operational  architecture  to  include  the  full  collection  of  relationship  diagrams  developed 
modeling  the  contact  prosecution  process  and  the  associated  activation  and  controls  of  the 
functions.  In  addition,  this  appendix  provides  further  detail  of  the  Arena®  model  of  the 
contact  prosecution  and  the  results  of  the  simulations  conducted. 

A.  CONTACT  PROSECUTION 

This  section  presents  the  key  thread  of  processes  converting  inputs  into  outputs 
for  contact  prosecution.  First,  the  collection  of  relationship  diagrams  using  the  IDEFO 
methodology  is  presented.  Second,  the  activation  and  controls  of  the  pertinent  functions 
in  the  contact  prosecution  process  is  presented. 
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Figure  64. 


Relationship  Diagram  -  CPOa 
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Figure  65. 


Relationship  Diagram  -  CPOb 
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Figure  66.  Relationship  Diagram  -  CP02a 
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Figure  67.  Relationship  Diagram  -  CP02b 
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Figure  68.  Relationship  Diagram  -  CP02 1 
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Figure  69.  Relationship  Diagram  -  CP022 
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Figure  70.  Relationship  Diagram  -  CP05 
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Figure  7 1 .  Relationship  Diagram  -  CP05 1 
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Figure  72.  Relationship  Diagram  -  CP05 1 1 
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Figure  73.  Relationship  Diagram  -  CP052 
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Figure  74.  Relationship  Diagram  -  CP06a 
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Required  Tasks 


Figure  76.  Relationship  Diagram  -  CP061 
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NODE:  CP061  TITLE:  Contact  Prosecution  -  Evaluate  Response  Options  NO.:  005 


F igure  7 7 .  Relationship  Diagram  -  CP06 1 3 
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F igure  7 8 .  Relationship  Diagram  -  CP06 1 4 
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Function _  Output _  Required  Inputs  Required  Controls 


1.0 

Transport 

Information 

-  Transported  Data 

-  Transport  Data 

N/A 

2.0 

Process  Information 

-  Transport  Data 

-  Response  Option 

-  Communication  Protocols 

-  Response 

-  Communication  Protocols 

-  Order 

-  Communication  Protocols 

-  Expected 
Circumstances 

-  Communication  Protocols 

-  Infeasible  Response 

-  Communication  Protocols 

-  Incomplete  Response 

-  Communication  Protocols 

-  Unassigned  Tasks 

-  Communication  Protocols 

-  Illegal  Response 

-  Communication  Protocols 

-  Immoral  Response 

-  Communication  Protocols 

-  Immoral  Tasks 

-  Communication  Protocols 

-  Past  Experiences 

-  Stored  Data 

-  Communication  Protocols 

-  Resources' 
Capabilities 

-  Stored  Data 

-  Communication  Protocols 

-  Response  Option 
Output 

-  Response  Option 

-  Communication  Protocols 

-  Response  Option 

Data 

-  Communication  Protocols 

-  Assignment 

-  Transported  Data 

-  Communication  Protocols 

-  Warning 

-  Transported  Data 

-  Communication  Protocols 

-  Assignment  Output 

-  Transported  Data 

-  Communication  Protocols 

-  Warning  Output 

-  Transported  Data 

-  Communication  Protocols 

-  Circumstance 

Output 

-  Transported  Data 

-  Communication  Protocols 

-  Intent  Output 

-  Transported  Data 

-  Communication  Protocols 

-  Response 

-  Transported  Data 

-  Past  Experiences 

-  Infeasible  Response 

-  Transported  Data 

-  Past  Experiences 

-  Incomplete 

Response 

-  Transported  Data 

-  Past  Experiences 

-  Illegal  Response 

-  Transported  Data 

-  Past  Experiences 

-  Immoral  Response 

-  Transported  Data 

-  Past  Experiences 

-  Unassigned  Tasks 

-  Transported  Data 

-  Past  Experiences 

-  Immoral  Tasks 

-  Transported  Data 

-  Past  Experiences 

-  Expected 
Circumstances 

-  Transported  Data 

-  Past  Experiences 

-  Response  Option 

-  Transported  Data 

-  Past  Experiences 

-  Order 

-  Order 

-  Past  Experiences 

-  Current 
Circumstances 

-  Transported  Data 

-  Past  Experiences 

-  Past  Circumstances 

-  Transported  Data 

-  Past  Experiences 

-  Established  Intent 

-  Transported  Data 

-  Past  Experiences 

2.1 

Convert  Data 

-  Transport  Data 

-  Response  Option 

-  Communication  Protocols 

-  Response 

-  Communication  Protocols 

-  Order 

-  Communication  Protocols 

-  Expected 
Circumstances 

-  Communication  Protocols 

-  Infeasible  Response 

-  Communication  Protocols 

-  Incomplete  Response 

-  Communication  Protocols 

-  Unassigned  Tasks 

-  Communication  Protocols 

-  Illegal  Response 

-  Communication  Protocols 

-  Immoral  Response 

-  Communication  Protocols 

-  Immoral  Tasks 

-  Communication  Protocols 

-  C2  Data 

-  Transported  Data 

-  Communication  Protocols 

-  Past  Data 

-  Stored  Data 

-  Communication  Protocols 

-  Past  Experiences 

-  Stored  Data 

-  Communication  Protocols 

199 


-  Resources' 
Capabilities 

-  Stored  Data 

-  Communication  Protocols 

-  Order 

-  Communication  Protocols 

-  Input  Data 

-  Sensor  System 
Information 

-  Communication  Protocols 

-  Weapon  System 
Information 

-  Communication  Protocols 

-  Platfonn  Information 

-  Communication  Protocols 

-  Assignment 

-  Assignment  Data 

-  Communication  Protocols 

-  Warning 

-  Warning  Data 

-  Communication  Protocols 

-  Assignment  Output 

-  Assignment  Data 

-  Communication  Protocols 

-  Warning  Output 

-  Warning  Data 

-  Communication  Protocols 

-  Response  Option 
Output 

-  Response  Option 

Data 

-  Communication  Protocols 

-  Circumstance 

Output 

-  Circumstance  Data 

-  Communication  Protocols 

-  Intent  Output 

-  Intent  Data 

-  Communication  Protocols 

-  Response  Option 

-  Communication  Protocols 

-  Response 

-  Communication  Protocols 

-  Order 

-  Communication  Protocols 

-  Expected 
Circumstances 

-  Communication  Protocols 

2.1.1 

Transport  Conversion 

-  Transport  Data 

-  Infeasible  Response 

-  Communication  Protocols 

-  Incomplete  Response 

-  Communication  Protocols 

-  Unassigned  Tasks 

-  Communication  Protocols 

-  Illegal  Response 

-  Communication  Protocols 

-  Immoral  Response 

-  Communication  Protocols 

-  Immoral  Tasks 

-  Communication  Protocols 

-  C2  Data 

-  Transported  Data 

-  Communication  Protocols 

2.1.2 

Storage  Conversion 

-  Past  Data 

-  Stored  Data 

-  Communication  Protocols 

-  Past  Experiences 

-  Stored  Data 

-  Communication  Protocols 

-  Order 

-  Communication  Protocols 

2.1.3 

Input  Conversion 

-  Input  Data 

-  Sensor  System 
Information 

-  Communication  Protocols 

-  Weapon  System 
Information 

-  Communication  Protocols 

-  Platform  Information 

-  Communication  Protocols 

-  Assignment 

-  Assignment  Data 

-  Communication  Protocols 

-  Warning 

-  Warning  Data 

-  Communication  Protocols 

-  Assignment  Output 

-  Assignment  Data 

-  Communication  Protocols 

-  Warning  Output 

-  Warning  Data 

-  Communication  Protocols 

2.1.4 

Output  Conversion 

-  Response  Option 
Output 

-  Response  Option 

Data 

-  Communication  Protocols 

-  Circumstance 

Output 

-  Circumstance  Data 

-  Communication  Protocols 

-  Intent  Output 

-  Intent  Data 

-  Communication  Protocols 

-  Valid  Past  Data 

-  Past  Data 

-  Past  Experiences 

2.2 

Evaluate  Information 

-  Valid  Input  Data 

-  Input  Data 

-  Past  Experiences 

-  Valid  C2  Data 

-  C2  Data 

-  Past  Experiences 

Evaluate  accuracy  of 
information 

-  Past  Data 

-  Past  Experiences 

2.2.1 

-  Accurate  Data 

-  Input  Data 

-  Past  Experiences 

-  C2  Data 

-  Past  Experiences 

Evaluate  completeness 
of  information 

-  Valid  Past  Data 

-  Accurate  Data 

-  Past  Experiences 

2.2.2 

-  Valid  Input  Data 

-  Accurate  Data 

-  Past  Experiences 

-  Valid  C2  Data 

-  Accurate  Data 

-  Past  Experiences 

-  Information 

-  Past  Experiences 

2.3 

Analyze  information 

-  Data 

-  Executable  Response 

-  Past  Experiences 

-  Data 

-  Past  Experiences 
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-  Assignment  Data 

-  Information 

-  Past  Experiences 

-  Warning  Data 

-  Information 

-  Past  Experiences 

-  Response  Option 

Data 

-  Information 

-  Past  Experiences 

-  Circumstance  Data 

-  Information 

-  Past  Experiences 

-  Intent  Data 

-  Information 

-  Past  Experiences 

-  Valid  Input  Data 

-  Past  Experiences 

-  Valid  Past  Data 

-  Past  Experiences 

-  Information 

-  Response  Option 

Data 

-  Past  Experiences 

-  Data 

-  Past  Experiences 

-  Response 

-  Valid  C2  Data 

-  Past  Experiences 

-  Infeasible  Response 

-  Valid  C2  Data 

-  Past  Experiences 

-  Incomplete 

Response 

-  Valid  C2  Data 

-  Past  Experiences 

-  Illegal  Response 

-  Valid  C2  Data 

-  Past  Experiences 

2.4 

Synthesize  information 

-  Immoral  Response 

-  Valid  C2  Data 

-  Past  Experiences 

-  Unassigned  Tasks 

-  Valid  C2  Data 

-  Past  Experiences 

-  Immoral  Tasks 

-  Valid  C2  Data 

-  Past  Experiences 

-  Expected 
Circumstances 

-  Valid  C2  Data 

-  Past  Experiences 

-  Response  Option 

-  Valid  C2  Data 

-  Past  Experiences 

-  Order 

-  Valid  C2  Data 

-  Past  Experiences 

-  Current 
Circumstances 

-  Valid  C2  Data 

-  Past  Experiences 

-  Past  Circumstances 

-  Valid  C2  Data 

-  Past  Experiences 

-  Established  Intent 

-  Valid  C2  Data 

-  Past  Experiences 

3.0 

Store  information 

-  Stored  Data 

-  Storage  Data 

N/A 

-  Assignment  Output 

-  HSI  Requirements 

-  Warning  Output 

-  HSI  Requirements 

4.0 

Present  information 

-  Presented  Data 

-  Circumstance  Output 

-  HSI  Requirements 

-  Intent  Output 

-  HSI  Requirements 

-  Response  Option 
Output 

-  HSI  Requirements 

5.0 

Generate  response 

-  Response  Option 

-  Current 

Circumstances 

-  Past  Circumstances 

-  Established  Intent 

-  Past  Experiences 

-  Law  of  Armed  Conflict 

-  Rules  of  Engagement 

-  Weapons  Control  Status 

-  No  Strike  List 

-  Restricted  Target  List 

-  Tactics,  Techniques,  and 
Procedures 

-  Pre-planned  Responses 

-  Resources'  Capabilities 

options 

-  Current 

Circumstances 

-  Expected 
Circumstances 

-  Established  Intent 

-  Response 

-  Past  Experiences 

-  Law  of  Armed  Conflict 

-  Rules  of  Engagement 

-  Weapons  Control  Status 

-  No  Strike  List 

-  Restricted  Target  List 

-  Tactics,  Techniques,  and 
Procedures 

-  Pre-planned  Responses 

-  Resources'  Capabilities 
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-  Established  Intent 

-  Infeasible  Response 

-  Past  Experiences 

-  Law  of  Armed  Conflict 

-  Rules  of  Engagement 

-  Weapons  Control  Status 

-  No  Strike  List 

-  Restricted  Target  List 

-  Tactics,  Techniques,  and 
Procedures 

-  Pre-planned  Responses 

-  Resources'  Capabilities 

-  Infeasible  Response 

-  Past  Experiences 

-  Law  of  Armed  Conflict 

-  Rules  of  Engagement 

-  Weapons  Control  Status 

-  No  Strike  List 

-  Restricted  Target  List 

-  Tactics,  Techniques,  and 
Procedures 

-  Pre-planned  Responses 

-  Resources'  Capabilities 

-  Established  Intent- 
Incomplete  Response- 
Unassigned  Tasks 

-  Past  Experiences-  Law  of 
Aimed  Conflict-  Rules  of 
Engagement-  Weapons 
Control  Status-  No  Strike 
List-  Restricted  Target  List- 
Tactics,  Techniques,  and 
Procedures-  Pre-planned 
Responses-  Resources' 
Capabilities 

-  Incomplete  Response 

-  Unassigned  Tasks 

-  Past  Experiences 

-  Law  of  Armed  Conflict 

-  Rules  of  Engagement 

-  Weapons  Control  Status 

-  No  Strike  List 

-  Restricted  Target  List 

-  Tactics,  Techniques,  and 
Procedures 

-  Pre-planned  Responses 

-  Resources'  Capabilities 

-  Illegal  Response 

-  Past  Experiences 

-  Law  of  Armed  Conflict 

-  Rules  of  Engagement 

-  Weapons  Control  Status 

-  No  Strike  List 

-  Restricted  Target  List 

-  Tactics,  Techniques,  and 
Procedures 

-  Pre-planned  Responses 

-  Resources'  Capabilities 

-  Established  Intent 

-  Immoral  Response 

-  Immoral  Tasks 

-  Past  Experiences 

-  Law  of  Armed  Conflict 

-  Rules  of  Engagement 

-  Weapons  Control  Status 

-  No  Strike  List 

-  Restricted  Target  List 

-  Tactics,  Techniques,  and 
Procedures 

-  Pre-planned  Responses 

-  Resources'  Capabilities 
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-  Immoral  Response 

-  Immoral  Tasks 

-  Past  Experiences 

-  Law  of  Armed  Conflict 

-  Rules  of  Engagement 

-  Weapons  Control  Status 

-  No  Strike  List 

-  Restricted  Target  List 

-  Tactics,  Techniques,  and 
Procedures 

-  Pre-planned  Responses 

-  Resources'  Capabilities 

-  Required  Tasks 

-  Current 

Circumstances-  Past 
Circumstances- 
Established  Intent 

-  Past  Experiences-  Law  of 
Armed  Conflict-  Rules  of 
Engagement-  Weapons 
Control  Status-  No  Strike 
List-  Restricted  Target  List- 
Tactics,  Techniques,  and 
Procedures-  Pre-planned 
Responses 

-  Current 

Circumstances 

-  Expected 
Circumstances 

-  Established  Intent 

-  Past  Experiences 

-  Law  of  Armed  Conflict 

-  Rules  of  Engagement 

-  Weapons  Control  Status 

-  No  Strike  List 

-  Restricted  Target  List 

-  Tactics,  Techniques,  and 
Procedures 

-  Pre-planned  Responses 

-  Established  Intent 

-  Infeasible  Response 

-  Past  Experiences 

-  Tactics,  Techniques,  and 
Procedures 

-  Pre-planned  Responses 

-  Established  Intent 

-  Incomplete  Response 

-  Unassigned  Tasks 

-  Past  Experiences 

-  Established  Intent 

-  Immoral  Response 

-  Immoral  Tasks 

-  Past  Experiences 

5.1 

Determine  changing 
circumstances 

-  Verified  Changing 
Circumstances 

-  Current 

Circumstances 

-  Past  Circumstances 

-  Past  Experiences 

-  Current 

Circumstances 

-  Expected 
Circumstances 

-  Past  Experiences 

5.1.1 

Detect  changing 
circumstances 

-  Changing 
Circumstances 

-  Current 

Circumstances 

-  Past  Circumstances 

-  Past  Experiences 

-  Current 

Circumstances 

-  Expected 
Circumstances 

-  Past  Experiences 

5.1. 1.1 

Detect  differences 
between  current  and 
past  circumstances 

-  Changing 
Circumstances 

-  Current 

Circumstances 

-  Past  Circumstances 

N/A 

5.1. 1.2 

Detect  differences 
between  current  and 
expected 
circumstances 

-  Changing 
Circumstances 

-  Current 

Circumstances 

-  Expected 
Circumstances 

N/A 

5.1.2 

Identify  changing 
circumstances 

-  Identified  Changing 
Circumstances 

-  Changing 
Circumstances 

-  Past  Experiences 
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5.1.3 

Classify  changing 
circumstances 

-  Classified  Changing 
Circumstances 

-  Identified  Changing 
Circumstances 

-  Past  Experiences 

5.1.4 

Confirm  changing 
circumstances 

-  Verified  Changing 
Circumstances 

-  Classified  Changing 
Circumstances  [X2] 

N/A 

5.2 

Determine  required 
tasks 

-  Required  Tasks 

-  Verified  Changing 
Circumstances- 
Established  Intent 

-  Past  Experiences-  Law  of 
Armed  Conflict-  Rules  of 
Engagement-  Weapons 
Control  Status-  No  Strike 
List-  Restricted  Target  List- 
Tactics,  Techniques,  and 
Procedures-  Pre-planned 
Responses 

-  Established  Intent 

-  Infeasible  Response 

-  Past  Experiences 

-  Tactics,  Techniques,  and 
Procedures 

-  Pre-planned  Responses 

-  Established  Intent 

-  Incomplete  Response 

-  Unassigned  Tasks 

-  Past  Experiences 

-  Established  Intent 

-  Immoral  Response 

-  Immoral  Tasks 

-  Past  Experiences 

5.2.1 

Identify  specified  tasks 

-  Specified  Tasks 

-  Verified  Changing 
Circumstances 

-  Established  Intent 

-  Law  of  Armed  Conflict 

-  Rules  of  Engagement 

-  Weapons  Control  Status 

-  No  Strike  List 

-  Restricted  Target  List 

-  TTPs 

-  PPRs 

5.2.2 

Hypothesize  implicit 
tasks 

-  Implicit  Tasks 

-  Verified  Changing 
Circumstances 

-  Established  Intent 

-  Past  Experiences 

-  Law  of  Armed  Conflict 

-  Rules  of  Engagement 

-  Weapons  Control  Status 

-  No  Strike  List 

-  Restricted  Target  List 

-  TTPs 

-  PPRs 

-  Specified  Tasks 

5.2.3 

Hypothesize  emergent 
tasks 

-  Emergent  Tasks 

-  Verified  Changing 
Circumstances 

-  Established  Intent 

-  Past  Experiences 

-  Law  of  Armed  Conflict 

-  Rules  of  Engagement 

-  Weapons  Control  Status 

-  No  Strike  List 

-  Restricted  Target  List 

-  TTPs 

-  PPRs 

-  Specified  Tasks 

5.2.4 

Confirm  Required 

Tasks 

-  Required  Tasks 

-  Established  Intent 

-  Infeasible  Response 

-  Past  Experiences 

-TTPs 

-PPRs 

-  Established  Intent 

-  Incomplete  Response 

-  Unassigned  Tasks 

-  Past  Experiences 

-  Established  Intent- 
Immoral  Response- 
Immoral  Tasks 

-  Past  Experiences 
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5.3 


Identify  resources  for 
required  tasks 


-  Solution  Space 


-  Required  Tasks 

-  Past  Experiences 

-  Law  of  Armed  Conflict 

-  Rules  of  Engagement 

-  Weapons  Control  Status 

-  No  Strike  List 

-  Restricted  Target  List 

-  TTPs 

-  PPRs 

-  Resources'  Capabilities 

-  Response 

-  Past  Experiences 

-  Law  of  Armed  Conflict 

-  Rules  of  Engagement 

-  Weapons  Control  Status 

-  No  Strike  List 

-  Restricted  Target  List 

-  Tactics,  Techniques,  and 
Procedures 

-  Pre-planned  Responses 

-  Resources'  Capabilities 

-  Infeasible  Resposne 

-  Past  Experiences 

-  Law  of  Armed  Conflict 

-  Rules  of  Engagement 

-  Weapons  Control  Status 

-  No  Strike  List 

-  Restricted  Target  List 

-  Tactics,  Techniques,  and 
Procedures 

-  Pre-planned  Responses 

-  Resources'  Capabilities 

-  Unassigned  Tasks 

-  Incomplete  Response 

-  Past  Experiences 

-  Law  of  Armed  Conflict 

-  Rules  of  Engagement 

-  Weapons  Control  Status 

-  No  Strike  List 

-  Restricted  Target  List 

-  Tactics,  Techniques,  and 
Procedures 

-  Pre-planned  Responses 

-  Resources'  Capabilities 

-  Illegal  Response 

-  Past  Experiences 

-  Law  of  Armed  Conflict 

-  Rules  of  Engagement 

-  Weapons  Control  Status 

-  No  Strike  List 

-  Restricted  Target  List 

-  Tactics,  Techniques,  and 
Procedures 

-  Pre-planned  Responses 

-  Resources'  Capabilities 

-  Immoral  Response 

-  Past  Experiences-  Law  of 
Aimed  Conflict-  Rules  of 
Engagement-  Weapons 
Control  Status-  No  Strike 
List-  Restricted  Target  List- 
Tactics,  Techniques,  and 
Procedures-  Pre-planned 
Responses-  Resources' 
Capabilities 
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5.4 

Allocate  resources  for 
required  tasks 

-  Response  Option 

-  Solution  Space 

-  Past  Experiences 

-  Law  of  Armed  Conflict 

-  Rules  of  Engagement 

-  Weapons  Control  Status 

-  No  Strike  List 

-  Restricted  Target  List 

-  Tactics,  Techniques,  and 
Procedures 

-  Pre-planned  Responses 

-  Resources'  Capabilities 

-  Required  Tasks 

6.0 

Select  response 
options 

Executable  Response 

-  Response  Option 

-  Resources' 

Capabilities 

-  Past  Experiences 

-  Established  Intent 

-  Required  Tasks 

-  Law  of  Armed  Conflict 

-  Rules  of  Engagement 

-  Weapons  Control  Status 

-  No  Strike  List 

-  Restricted  Target  List 

-  Tactics,  Techniques,  and 
Procedures 

-  Pre-planned  Responses 

-  Ethics 

Expected 

Circumstances 

-  Complete  Response 

-  Resources’ 

Capabilities 

-  Current 

Circumstances 

-  Past  Experiences 

-  Required  Tasks 

-  Law  of  Armed  Conflict 

-  Rules  of  Engagement 

-  Weapons  Control  Status 

-  No  Strike  List 

-  Restricted  Target  List 

6.1 

Evaluate  response 
options 

-  Evaluated  Response 

-  Response  Option 

-  Resources' 

Capabilities 

-  Current 

Circumstances 

-  Past  Experiences 

-  Established  Intent 

-  Required  Tasks 

-  Law  of  Armed  Conflict 

-  Rules  of  Engagement 

-  Weapons  Control  Status 

-  No  Strike  List 

-  Restricted  Target  List 

Expected 

Circumstances 

-  Complete  Response 

-  Resources’ 

Capabilities 

-  Current 

Circumstances 

-  Past  Experiences 

-  Required  Tasks 

-  Law  of  Armed  Conflict 

-  Rules  of  Engagement 

-  Weapons  Control  Status 

-  No  Strike  List 

-  Restricted  Target  List 

6.1.1 

Evaluate  feasibility  of 
options 

-  Feasible  Response 

-  Infeasible  Response 

-  Legal  Response 

-  Resources' 

Capabilities 

-  Required  Tasks 

6.1.2 

Evaluate  completeness 
of  options 

-  Complete  Response 

-  Incomplete 

Response 

-  Feasible  Response 

-  Resources' 

Capabilities 

-  Required  Tasks 

-  Unassigned  Tasks 

-  Feasible  Response 

-  Resources' 

Capabilities 

-  Required  Tasks 

6.1.3 

Evaluate  legality  of 
options 

-  Legal  Response 

-  Illegal  Response 

-  Response  Option 

-  Law  of  Armed  Conflict 

-  Rules  of  Engagement 

-  Weapons  Control  Status 

-  No  Strike  List 

-  Restricted  Target  List 
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6. 1.3.1 

Compare  assigned 
tasks  with  law  of 
anned  conflict 

-  LOAC  Complied 
Response 

-  Illegal  Response 

-  Response  Option 

-  Law  of  Armed  Conflict 

6. 1.3.2 

Compare  assigned 
tasks  with  rules  of 
engagement 

-  Legal  Response 

-  Illegal  Response 

-  LOAC  Complied 
Response 

-  Rules  of  Engagement 

-  Weapons  Control  Status 

-  No  Strike  List 

-  Restricted  Target  List 

6.1.4 

Estimate  effectiveness 
of  option 

-  Evaluated  Response 

-  Complete  Response 

-  Resources' 

Capabilities 

-  Current 

Circumstances 

-  Past  Experiences 

-  Established  Intent 

-  Expected 
Circumstances 

-  Complete  Response 

-  Resources' 

Capabilities 

-  Current 

Circumstances 

-  Past  Experiences 

6.1.4.1 

Hypothesize  expected 
circumstances 

-  Expected 
Circumstances 

-  Complete  Response 

-  Resources' 

Capabilities 

-  Past  Experiences 

6. 1.4.2 

Estimate  measures  of 
effectiveness 

-  Evaluated  Response 

-  Complete  Response 

-  Resources' 

Capabilities 

-  Current 

Circumstances 

-  Expected 
Circumstances 

-  Past  Experiences 

-  Established  Intent 

6.2 

Judge  response  options 

-  Response 

-  Immoral  Response 

-  Evaluated  Response 

-  Past  Experiences 

-  Established  Intent 

-  Ethics 

6.3 

Assign  tasks  to 
resources 

-  Executable 

Response 

-  Response 

-  Tactics,  Techniques,  and 
Procedures 

-  Pre-planned  Responses 

Table  33.  Contact  Prosecution  -  Function  Activation  and  Control 


B.  ARENA®  MODELS  OF  THE  CONTACT  PROSECUTION  PROCESS 

To  demonstrate  the  feasibility  of  using  the  developed  architectural  framework  to 
analyze  and  compare  alternative  designs,  Arena®,  version  10.0,  was  used.  Arena®  is  a 
discrete-event  modeling  and  simulation  software  developed  by  Rockwell  Automation, 
Inc.  This  section  presents  the  developed  Arena®  models  of  the  contact  prosecution 
process  and  the  subsequent  simulation  results. 

1.  The  Models 

Arena®  was  used  to  develop  two  models,  one  for  each  of  the  alternative 
architectures  of  the  system.  The  models  represent  a  portion  of  the  notional  contact 
prosecution  process  discussed  in  Chapter  VII  and  detailed  in  the  previous  sections  of  this 
thesis.  The  top-level  diagram,  which  is  identical  for  both  models,  is  presented  in  Figure 
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79.  The  diagram  shows  the  three  top-level  functions  which  are  a  part  of  the  process: 
Transport  Information,  Process  Information,  and  Select  Response  Options.  The  other 
items  in  the  diagram  are  for  the  creation  and  disposal  of  the  entities  (i.e.,  response  options 
and  responses)  flowing  through  the  model,  as  well  as  for  measuring  and  controlling  the 
flow  of  the  entities. 


Figure  79.  Arena®  Model  -  Top-level 

In  both  models,  the  first  step  is  the  creation  of  a  response  option.  The  response 
option  is  then  copied;  the  number  of  copies  detennined  by  the  selected  architecture.  The 
response  option  and  its  copies  are  then  processed,  transported,  and  processed  again  to 
serve  as  an  input  to  Select  Response  Options.  The  first  response  to  arrive  at  a  particular 
line  of  mechanisms  is  used.  All  other  copies  sent  to  such  line  of  mechanisms  are 
discarded.  The  response  option  is  then  evaluated  and  judged.  If  the  response  option  is 
determined  to  be  either  illegal,  infeasible,  incomplete,  or  immoral,  it  is  sent  to  Redo  CPOa 
to  serve  as  input  for  the  generation  of  another  response  option.  If  it  is  determined  to  be 
legal,  feasible,  incomplete,  and  moral,  it  becomes  a  response.  The  response  is  copied 
multiple  times,  again  as  determined  by  the  selected  architecture.  The  response  is  then 
processed,  transported,  and  processed  to  serve  as  input  for  Select  Response  Options 
where  tasks  are  assigned  to  resources.  Again,  the  first  response  to  arrive  at  a  particular 
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line  of  mechanisms  is  used  while  all  other  responses  are  discarded.  Once  the  assignments 
are  complete,  the  response  becomes  an  executable  response  and  the  model  is  complete. 

The  use  of  Arena®  to  model  the  selected  portion  of  the  contact  prosecution 
process  required  the  adaptation  of  the  previously  generated  relationship  diagrams  along 
with  the  integration  of  the  identified  functional  activations.  Whenever  possible,  the 
author  attempted  to  construct  the  Arena®  models  to  flow,  both  visually  and  logically,  as 
the  previously  generated  relationship  diagrams.  In  addition,  many  logical  decision  points 
were  included  throughout  the  model  to  control  the  flow  of  the  entities  (e.g.,  response 
options  and  responses). 

A  major  challenge  faced,  due  to  the  selection  of  Arena®  as  the  modeling  and 
simulation  software,  was  the  modeling  of  the  systems  resources.  Arena®  does  provide  a 
simple  module  for  managing  resources,  to  include  the  number  available  to  the  system  and 
the  rules  for  each  resources  use.  The  software  also  allows  for  a  straight-forward 
assignment  of  a  resource,  or  a  set  of  resources,  to  a  given  function.  The  difficulty  with 
using  Arena®  arose  when  trying  to  model  the  parallel  paths  associated  with  a  distributed 
network.  To  overcome  this  challenge,  most  functions  were  further  dissected  logically  to 
ensure  a  particular  entity  was  assigned  the  corresponding  mechanism.  For  example,  as 
shown  in  Figure  80.  and  Figure  81.  ,  responses  being  transported  were  first  separated 
according  to  their  destination  line-of-mechanisms  in  Select  Response  Options  and  then 
according  to  the  specific  link  to  be  used  for  transport.  This  was  done  to  ensure  that  the 
entities  were  properly  delayed  and  queues  for  future  mechanisms  were  properly 
established.  This  approach,  however,  makes  the  model  cumbersome  and  difficult  to  scale 
(e.g.,  adding  more  parallel  subordinate  commanders).  Though  a  better  approach  to 
account  for  these  difficulties  may  have  been  possible  using  Arena®,  such  application  was 
beyond  the  skill  of  the  author. 
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Figure  80.  Arena®  Model  -  Transport  Information 


The  model  for  Alternative  #2  was  developed  first.  From  this,  the  model  for 
Alternative  #1  was  created  by  reducing  the  number  of  copies  of  response  options  and 
responses  generated.  In  essence,  for  Alternative  #1,  copies  of  response  options  and 
responses  were  made  only  to  follow  the  top  line-of-mechanisms  for  Select  Response 
Options  of  Alternative  #2,  when  appropriate.  This  approach  ensured  the  attributes  and 
characteristics  of  each  function  and  resource  remained  consistent  between  models.  The 
only  other  significant  changes  between  models  involved  the  respective  collection  of  data. 
Figure  82.  through  Figure  86.  present  selected  views  of  the  Arena®  models  developed. 
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Table  34.  shows  the  distributions  and  resources  associated  with  each  function.  The 
section  following  discusses  the  simulations  and  results. 


Figure  82.  Arena®  Model  -  Process  Information 
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Figure  84.  Arena®  Model  -  Evaluate  Response  Options 


Figure  85.  Arena®  Model  -  Judge  Response  Options 
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Figure  86.  Arena®  Model  -  Assign  Tasks  to  Resources 
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Function 

Distribution 

Resources 

1.0 

Transport  Information 

Normal  (0.0005,0.0001) 

Links  -  3  per  line- 
of-mechanisms 

2.1.1 

Transport  Conversion 

Normal  (0.05,  0.01) 

Processor  -  1  per 
link  per  line-of- 
mechanisms 

2.2.1 

Evaluate  Accuracy  of  Data 

Normal  (0.05,  0.01) 

Processors  -  1  per 
line-of-mechanisms 

2.2.2 

Evaluate  Completeness  of 
Data 

Normal  (0.05,  0.01) 

Processors  -  1  per 
line-of-mechanisms 

2.3 

Analyze  Information 

Normal  (1.0,  0.2) 

Processors  -  1  per 
line-of-mechanisms 

2.4 

Synthesize  Information 

Normal  (0.2,  0.02) 

Processors  -  2  per 
line-of-mechanisms 

6.1.1 

Evaluate  feasibility  of 
options 

Normal  (0.08,  0.02) 

Processors  -  1  per 
line-of-mechanisms 

6.1.2 

Evaluate  completeness  of 
options 

Normal  (0.05,  0.01) 

Processors  -  1  per 
line-of-mechanisms 

6.1.3. 1 

Compare  assigned  tasks 
with  law  of  anned  conflict 

Normal  (0.05,  0.01) 

Processors  -  1  per 
line-of-mechanisms 

6. 1.3.2 

Compare  assigned  tasks 
with  rules  of  engagement 

Normal  (0.05,  0.01) 

Processors  -  1  per 
line-of-mechanisms 

6. 1.4.1 

Hypothesize  expected 
circumstances 

Normal  (1.0,  0.2) 

Processors  -  1  per 
line-of-mechanisms 

6. 1.4.2 

Estimate  measures  of 
effectiveness 

Normal  (0.8,  0.2) 

Processors  -  1  per 
line-of-mechanisms 

6.2 

Judge  Response  Options 

Normal  (3.0,  1.0) 

Subordinate 
Commander  -  1  per 
line-of-mechanisms 

6.3 

Assign  Tasks  to  Resources 

Normal  (5.0,  1.0) 

Processors  -  4  per 
line-of-mechanisms 

N/A 

Redo  CP06a  (e.g.,  make 
new  response  option) 

Triangle  (3.0,  5.0,  10.0) 

N/A 

Table  34.  Associated  Distributions  and  Resources  for  Functions 


2.  The  Simulation 

The  objective  of  simulating  the  two  models  was  to  demonstrate  possible 
performance  differences  in  the  alternative  architectures.  A  combination  of  three  MoMs 
from  the  systems  objective  hierarchy  was  selected  to  highlight  such  differences.  First, 
the  sum  of  MoP  5. 2. 2. 2,  time  between  response  option  being  developed  and  response 
decision,  and  MoP  6.2.1,  time  between  order  of  response  execution  by  decision- 
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authorized  entity  and  completion  of  allocations  by  allocation-authorized  entity,  was 
recorded  for  each  alternative  design.  Second,  MoCE  5.5,  consistency  of  response 
between  decision-authorized  entities,  was  also  recorded. 

Once  both  models  were  complete,  thirty  replications  were  conducted  for  each. 
Each  replication  began  with  a  warm-up  time  of  three  simulation-minutes  to  fill  queues 
and  task  resources  followed  by  ten  simulation-minutes  in  which  data  was  collected.  For 
both  alternative  models,  response  options  were  created  with  inter-arrival  times  following 
an  exponential  distribution  with  a  mean  of  1/5  s'1.  Asa  result,  approximately  100+ 
response  options  were  created  and  served  as  input  during  the  ten  operational  simulation- 
minutes. 

The  minimum  time  from  response  option  creation  until  the  generation  of  an 
associated  executable  response,  the  sum  of  MoP  5. 2.2. 2  and  MoP  6.2.1,  was  recorded  for 
each  response  option  and,  in  the  case  of  Alternative  #2,  for  each  line  of  Select  Response 
Option  mechanisms.  In  addition,  for  Alternative  #2,  the  executable  responses  for  each 
response  option  were  compared  to  determine  consistency  (i.e.,  MoCE  5.5).  Results  for 
the  model  of  Alternative  #1  are  presented  in  Table  35.  The  first  column  denotes  the 
replication  number.  The  second  column  denotes  the  average  time  for  one  of  the 
approximately  100+  response  options  to  generate  an  executable  response.  The  third 
column  denotes  the  equivalent  minimum  time  for  the  replication  while  the  fourth  column 
denotes  the  equivalent  maximum  time.  The  fifth  column  shows  the  number  of  response 
options  created  during  the  replication.  The  sixth  column  shows  the  number  of  executable 
responses  generated  from  the  response  options  for  the  replication.  Finally,  the  seventh 
column  presents  the  percentage  of  response  options  which  generate  executable  responses 
in  each  ten  simulation-minute  replication. 


216 


Time  from  Response  Option  to 
Executable  Response 

Response 

Options 

Generated 

Executable 

Responses 

Response 

Percentage 

# 

Avg 

Min 

Max 

1 

15.260 

9.556 

34.983 

132 

129 

97.73% 

2 

15.881 

8.517 

39.135 

131 

125 

95.42% 

3 

18.508 

9.653 

48.906 

138 

136 

98.55% 

4 

17.451 

7.466 

44.437 

131 

128 

97.71% 

5 

16.534 

8.528 

39.753 

138 

131 

94.93% 

6 

20.417 

9.235 

67.205 

134 

129 

96.27% 

7 

14.967 

8.783 

47.998 

116 

112 

96.55% 

8 

16.548 

8.972 

46.633 

122 

118 

96.72% 

9 

14.568 

8.915 

27.816 

108 

107 

99.07% 

10 

17.508 

9.194 

51.854 

133 

126 

94.74% 

11 

16.096 

8.003 

39.235 

115 

114 

99.13% 

12 

15.195 

9.007 

30.510 

117 

113 

96.58% 

13 

15.068 

7.138 

38.178 

124 

121 

97.58% 

14 

18.575 

8.999 

58.073 

141 

138 

97.87% 

15 

14. 755 

9.602 

32.627 

124 

122 

98.39% 

16 

15.021 

8.550 

30.509 

112 

109 

97.32% 

17 

16.670 

7.295 

38.159 

120 

116 

96.67% 

18 

15.047 

8.547 

36.435 

113 

110 

97.35% 

19 

17.186 

9.142 

37.730 

111 

108 

97.30% 

20 

16.971 

9.774 

40.362 

137 

134 

97.81% 

21 

14.671 

8.778 

34.410 

103 

101 

98.06% 

22 

16.787 

10.096 

37.522 

125 

123 

98.40% 

23 

16.435 

7.726 

36.008 

127 

124 

97.64% 

24 

14.987 

10.117 

29.551 

111 

107 

96.40% 

25 

16.714 

7.626 

51.489 

129 

128 

99.22% 

26 

15.492 

7.689 

34.432 

113 

111 

98.23% 

27 

16.877 

8.968 

38.586 

133 

133 

100.00% 

28 

16.256 

9.216 

35.771 

129 

124 

96.12% 

29 

17.875 

8.097 

43.541 

116 

113 

97.41% 

30 

15.085 

9.358 

31.910 

110 

106 

96.36% 

Table  35.  Alternative  #1  Arena®  Results 


Table  36.  presents  results  of  the  Alternative  #2  model,  specifically  the  minimum 
time  from  response  option  to  executable  response.  Again,  the  first  column  denotes  the 
replication  number.  To  understand  the  second  through  tenth  columns,  the  reader  must 
first  understand  the  ideas  of  grouping  and  consistency  as  they  apply  to  this  thesis  and 
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simulation.  At  the  beginning  of  the  Alternative  #2  model,  one  response  option  is  copied 
multiple  times  both  for  the  multiple  lines-of-mechanisms  in  Select  Response  Options  and 
for  the  multiple  links  used  in  Transport  Information.  Such  response  option  and  copies 
are  a  deemed  a  group.  When  during  Select  Response  Options  a  response  option  is 
deemed  illegal,  infeasible,  incomplete,  or  immoral,  it  is  return  to  Generate  Response 
Options  to  serve  as  input  for  a  new  response  option.  If  all  or  none  of  the  response  options 
return  to  Generate  Response  Options  then  the  group  of  executable  responses  which  will 
be  generated  from  the  original  response  option  will  be  consistent.  Otherwise,  they  will  be 
inconsistent. 

The  second,  third,  and  fourth  column  present  the  results  for  all  groups  of 
executable  responses,  the  fifth,  sixth,  and  seventh  for  all  groups  of  consistent  executable 
responses,  and  the  eighth,  ninth,  and  tenth  for  all  groups  of  inconsistent  executable 
responses.  In  each  column  group,  the  first  column  denotes  the  average  minimum  time, 
for  each  group  of  responses,  from  response  option  to  executable  response.  The  second 
and  third  in  each  column  group  present  minimum  time,  for  each  group  of  responses,  from 
response  option  to  executable  response,  minimum  and  maximum  respectively. 
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Minimum  time,  for 
group  of  responses, 
from  response  option  to 
executable  response: 

All  groups 

Minimum  time,  for 
group  of  responses, 
from  response  option  to 
executable  response: 

Consistent  groups 

Minimum  time,  for 
group  of  responses, 
from  response  option  to 
executable  response: 

Inconsistent  groups 

# 

Avg 

Min 

Max 

Avg 

Min 

Max 

Avg 

Min 

Max 

1 

19.048 

7.996 

37.035 

19.284 

7.996 

37.035 

17.791 

9.222 

34.587 

2 

14.189 

8.738 

26.970 

14.267 

8.738 

26.970 

13.459 

9.495 

21.464 

3 

15.278 

8.014 

37.152 

15.516 

8.014 

37.152 

14.115 

8.296 

29.317 

4 

15.024 

7.408 

32.707 

15.141 

7.408 

32.707 

14.348 

9.630 

25.869 

5 

15. 772 

8.589 

34.415 

15.723 

8.589 

34.415 

16.056 

9.309 

31.758 

6 

15.316 

6.398 

31.776 

15.308 

6.398 

31.776 

15.402 

9.876 

26.314 

7 

16.772 

8.968 

39.589 

16.360 

8.968 

38.538 

19.707 

10.777 

39.589 

8 

11.055 

7.670 

16.242 

11.085 

7.670 

16.242 

10.790 

9.439 

13.843 

9 

13.173 

8.095 

24.574 

13.157 

8.095 

24.574 

13.307 

8.704 

18.073 

10 

25.478 

7.266 

52.300 

25.181 

7.266 

51.403 

27.992 

9.497 

52.300 

11 

13.153 

7.861 

25.144 

12.694 

7.861 

25.144 

15.969 

9.374 

22.967 

12 

13.778 

8.139 

24.705 

13.695 

8.139 

24.705 

14.286 

9.576 

21.525 

13 

13.770 

8.115 

27.319 

13.756 

8.115 

27.319 

13.874 

10.611 

23.587 

14 

11.795 

7.412 

20.006 

11.792 

8.475 

20.006 

11.812 

7.412 

15.442 

15 

14.124 

8.049 

24.063 

14.089 

8.049 

24.063 

14.477 

9.102 

23.347 

16 

15.108 

7.396 

29.288 

14.924 

7.396 

29.288 

16.383 

10.647 

27.649 

17 

15.551 

8.813 

27.900 

15.366 

8.813 

27.900 

16.771 

9.510 

25.429 

18 

13.148 

6.963 

23.288 

13.170 

6.963 

23.288 

12.946 

8.659 

19.265 

19 

13.883 

7.287 

28.151 

13.959 

7.287 

28.151 

13.384 

9.623 

19.047 

20 

14.966 

8.309 

25.373 

14.520 

8.309 

23.536 

16.971 

9.009 

25.373 

21 

18.693 

6.994 

32.648 

18.249 

6.994 

31.376 

21.548 

9.604 

32.648 

22 

14.285 

8.038 

29.258 

13.850 

8.038 

27.662 

16.920 

10.098 

29.258 

23 

11.910 

7.307 

20.099 

11.870 

7.307 

20.099 

12.339 

7.970 

14.335 

24 

14.498 

8.088 

30.613 

14.035 

8.088 

30.613 

16.881 

8.861 

29.789 

25 

16.068 

8.488 

32.353 

15.758 

8.488 

29.285 

17.249 

9.927 

32.353 

26 

14. 728 

6.373 

29.513 

14.715 

8.155 

27.229 

14.797 

6.373 

29.513 

27 

13.283 

8.271 

21.733 

13.219 

8.271 

21.733 

13.628 

9.407 

20.754 

28 

14.582 

7.251 

28.030 

14.398 

7.251 

28.030 

16.160 

8.553 

26.094 

29 

14.810 

8.797 

37.425 

14.522 

8.797 

37.425 

16.285 

9.186 

31.815 

30 

15.405 

8.628 

35.001 

15.579 

8.631 

35.001 

14.486 

8.628 

27.359 

Table  36.  Alternative  #2  Arena®  Results  -  Minimum 

Time  from  Response  Option  to  Executable  Response 


Table  37.  presents  results  of  the  Alternative  #2  model,  specifically  the  time 

interval  between  executable  responses.  The  second  through  fifth  columns  denote  time 

intervals  for  groups  of  consistent  executable  responses  while  the  sixth  through  eighth 
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columns  denote  time  intervals  for  groups  of  inconsistent  executable  responses.  In  each 
column  group,  the  first  column  denotes  the  average  time  between  an  executable  response 
in  the  group  and  the  next  subsequent  executable  response.  The  second  and  third  columns 
of  each  column  group  denote  the  minimum  and  maximum  time  between  an  executable 


response  in  the  group  and  the  next  subsequent  executable  response,  respectively. 


Interval  between  Responses 

(Groups  of  Consistent  Reponses) 

Interval  between  Re 

(Groups  of  Inconsistent  1 

sponses 

Responses) 

# 

Avg 

Min 

Max 

Avg 

Min 

Max 

1 

4.338 

0.171 

11.529 

18.808 

4.722 

33.395 

2 

3.577 

0.074 

10.386 

17.229 

8.891 

30.378 

3 

4.411 

0.498 

14.263 

24.299 

10.299 

49.969 

4 

3.809 

0.103 

12.178 

18.906 

2.087 

29.842 

5 

4.351 

0.149 

18.226 

19.483 

9.028 

43.081 

6 

4.618 

0.319 

14.703 

22.753 

11.123 

37.728 

7 

4.559 

0.291 

19.228 

23.516 

8.647 

49.527 

8 

2.552 

0.868 

5.087 

17.003 

13.946 

27.850 

9 

3.341 

0.292 

7.813 

19.546 

9.783 

56.541 

10 

5.742 

0.217 

17.996 

28.281 

0.315 

63.333 

11 

3.604 

0.334 

9.920 

20.695 

12.751 

44.756 

12 

2.848 

0.227 

7.650 

18.143 

9.593 

29.001 

13 

4.234 

0.711 

14.817 

20.786 

13.163 

36.533 

14 

3.273 

0.165 

8.751 

15.596 

6.710 

19.708 

15 

3.022 

0.386 

10.041 

19.267 

10.706 

29.408 

16 

3.433 

0.364 

7.874 

17.091 

10.535 

35.511 

17 

3.949 

0.252 

14.000 

22.340 

11.385 

43.676 

18 

3.079 

0.337 

7.605 

16.004 

12.472 

22.337 

19 

3.402 

0.340 

9.079 

16.155 

9.968 

28.609 

20 

3.564 

0.332 

8.577 

15.955 

6.795 

27.760 

21 

3.879 

0.257 

11.245 

19.103 

5.999 

33.499 

22 

3.523 

0.143 

9.952 

15.451 

6.770 

23.675 

23 

3.248 

0.282 

11.943 

20.385 

9.618 

48.725 

24 

5.183 

0.095 

17.787 

19.518 

7.908 

40.171 

25 

4.416 

0.124 

11.017 

16.062 

8.284 

25.313 

26 

3.801 

0.163 

10.890 

18.861 

9.266 

39.118 

27 

3.446 

0.078 

9.017 

16.399 

6.085 

39.335 

28 

3.632 

0.372 

10.090 

20.283 

12.561 

32.125 

29 

3.179 

0.524 

8.265 

15.868 

8.301 

26.766 

30 

4.250 

0.360 

13.666 

20.276 

9.825 

32.209 

Table  37.  Alternative  #2  Arena®  Results  -  Time  Interval 
Between  Executable  Responses 
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Table  38.  presents  results  of  the  Alternative  #2  model.  The  second  column 
shows  the  number  of  response  options  created  during  the  replication.  The  third  column 
shows  the  number  of  groups  of  consistent  executable  responses  generated  from  the 
response  options.  The  fourth  column  shows  the  number  of  groups  of  inconsistent 
executable  responses  generated  from  the  response  options.  The  fifth  column  presents  the 
percentage  of  response  options  which  generate  executable  responses  in  each  ten 
simulation-minute  replication.  Finally,  the  sixth  column  presents  the  percentage  of 
executable  response  groups  which  are  consistent. 
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Response 

Options 

Generated 

Groups  of 
Consistent 
Responses 

Groups  of 
Inconsistent 
Responses 

Response 

Percentage 

Consistency 

Percentage 

# 

1 

135 

112 

21 

98.52% 

84.21% 

2 

118 

104 

11 

97.46% 

90.43% 

3 

125 

103 

21 

99.20% 

83.06% 

4 

117 

99 

17 

99.15% 

85.34% 

5 

132 

97 

17 

86.36% 

85.09% 

6 

131 

116 

11 

96.95% 

91.34% 

7 

132 

107 

15 

92.42% 

87.70% 

8 

93 

80 

9 

95.70% 

89.89% 

9 

120 

98 

12 

91.67% 

89.09% 

10 

146 

127 

15 

97.26% 

89.44% 

11 

108 

92 

15 

99.07% 

85.98% 

12 

125 

105 

17 

97.60% 

86.07% 

13 

110 

95 

13 

98.18% 

87.96% 

14 

97 

81 

14 

97.94% 

85.26% 

15 

119 

102 

10 

94.12% 

91.07% 

16 

127 

104 

15 

93.70% 

87.39% 

17 

134 

112 

17 

96.27% 

86.82% 

18 

105 

92 

10 

97.14% 

90.20% 

19 

118 

99 

15 

96.61% 

86.84% 

20 

122 

99 

22 

99.18% 

81.82% 

21 

145 

122 

19 

97.24% 

86.52% 

22 

129 

109 

18 

98.45% 

85.83% 

23 

107 

96 

9 

98.13% 

91.43% 

24 

131 

103 

20 

93.89% 

83.74% 

25 

124 

95 

25 

96.77% 

79.17% 

26 

114 

94 

18 

98.25% 

83.93% 

27 

131 

103 

19 

93.13% 

84.43% 

28 

126 

111 

13 

98.41% 

89.52% 

29 

102 

82 

16 

96.08% 

83.67% 

30 

119 

95 

18 

94.96% 

84.07% 

Table  38.  Alternative  #2  Arena®  Results  -  Response  Consistency 


Finally,  to  determine  possible  performance  differences  in  the  alternative 
architectures,  the  results  of  the  two  models  were  compared,  specifically  the  time  from 
response  option  to  executable  response.  The  second  column  of  and  the  second  column 
were  the  respective  data.  First,  an  F-Test  was  conducted  to  determine  if  the  variances  of 
the  two  data  sets  were  equal.  Specifically,  the  null  hypothesis  was  Ho:  a"i  =  a  2  and  the 
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test  hypothesis  was  Hp  cm  ^  a  2.  The  results  are  shown  in  Table  39.  Since  F  >  fo.0005 
(29,  29),  the  null  hypothesis  can  be  rejected  and  variances  are  assumed  to  be  unequal. 


F-Test: 

Two-sample  for  Variances 

Alternative  #1 

Alternative  #2 

Mean 

16.31342 

14.9548 

Variance 

1.911203 

6.914298 

Observations 

30 

30 

df 

29 

29 

F 

3.617773 

fo.0005  (29,  29) 

3.566697 

fo.9995  (29,  29) 

0.280371 

Table  39.  F-Test  Results 


Next,  a  t-test  was  conducted  to  detennine  if  the  mean  of  the  two  data  sets  were 
equal.  Since  the  variances  are  assumed  to  be  unequal  they  cannot  be  pooled. 
Specifically,  the  null  hypothesis  was  H0:  pi  =  p2  and  the  test  hypothesis  was  Hp  pi  >  p2. 
The  results  are  shown  in  Table  40.  Since  t  >  to.02  (43)  -  One -tail,  the  null  hypothesis  can 
be  rejected  and  it  can  be  assumed  that  the  mean  of  Alternative  #1  is  greater  than 
Alternative  #2. 


t-Test: 

Two-sample  for  Mean 

Alternative  #1 

Alternative  #2 

Mean 

16.31342 

14.9548 

Variance 

1.911203 

6.914298 

Observations 

30 

30 

Hypothesized  difference  in  means 

0 

df 

43 

t 

2.504906 

to. 02  (43)  -  One-tail 

2.41625 

Table  40.  t-Test  Results 


Alternative  #2  generates  executable  responses,  on  average,  in  less  time  than 
Alternative  #1,  but  with  more  variance.  In  addition,  Alternative  #2  generates  consistent 
executable  responses  approximately  87%  of  the  time.  Since  Alternative  #1  generates 
only  one  executable  response  for  each  response  option,  the  consistency  of  response  is 
100%  by  default.  The  above  simulations  and  analysis  demonstrates  the  possible 
performance  differences  between  the  two  alternative  designs.  However,  as  discussed  in 
Chapter  VII,  the  reader  is  warned  not  to  draw  specific  conclusions  on  perfonnance  of  the 
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alternative  system  designs  from  such  results.  Instead,  the  reader  should  be  encouraged 
that  modeling  and  simulation  can  determine  possible  performance  differences  in 
alternative  designs  using  the  architectural  framework  developed  in  this  thesis. 
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